Domain-Driven Design – Layered Applications

Jeffrey Palermo posted a diagram of his General Application Architecture, which hopefully he won’t mind, I have posted here as well to talk about.  All credit goes to Jeffrey for this diagram:



When I saw the diagram, it reminded me of Eric Evans’ book, Domain-Driven Design – Tackling Complexity in the Heart of Software.  In chapter 4 of the book, Isolating the Domain, Eric talks about layering your applications into highly cohesive, yet loosely coupled areas of concerns, called layers:


Layering an Application

“Partition a complex program into layers. Develop a design within each layer that is cohesive and that depends only on the layers below. Follow standard architectural patterns to provide loose coupling to the layers above.  Concentrate all the code related to the domain model in one layer and isolate it from the user interface, application, and infrastructure code. The domain objects, free of the responsibility of displaying themselves, storing themselves, managing application tasks, and so forth, can be focused on expressing the domain model. This allows a model to evolve to be rich enough and clear enough to capture essential business knowledge and put it to work [Evans p.71].”


This is really cool stuff, albeit much more complicated to actually develop than it is to describe in a paragraph or illustrate in a picture.  And, as even Eric discusses in his book, layers can be overkill if “a project needs to deliver simple functionality, dominated by data entry and display, with few business rules [Evans p.76],” and difficult to create if you don’t have the necessary OOP skills to pull off a highly cohesive, loosely-coupled layered application.  Eric references The Smart UI Anti-Pattern for your standard 2-tier database application


The Smart UI Anti-Pattern

“Put all the business logic into the user interface. Chop the application into small functions and implement them as separate user interfaces, embedding the business rules into them. Use a relational database as a shared repository of the data. Use the most automated UI building and visual programming tools available [Evans p.77].”



I agree with Jeffrey that I haven’t been able to find many open source, well architected, layered application from which to learn from, and the developer community could really benefit from such examples.  I do have to say that the Enterprise Library code looks good in my opinion.  Most of the examples on the Internet are more of the 2-tier database type applications, which promote placing much of the functionality and business rules into the UI.  And we wonder why it is so difficult to find skilled developers who understand how to build layered, highly cohesive, and loosely coupled applications.

The reason I bring this up, is because many of the topics I have been discussing here are a stepping-stone to these ideas.  The GRASP Patterns are a great foundation from which to learn the necessary skills to pull off these layered architectures.  There are nine GRASP Patterns in total and I have briefly only touched upon the Information Expert GRASP Pattern.  And, altough my examples were done quickly, I stumbled a number of times implementing the principle in the Create a Shopping Cart example, for which I will come out with another version :)

The book, Domain-Driven Design, talks about building and isolating a good domain model, but it isn’t a newbie book at all.  Although I highly recommend the book, it requires a good grasp of OOP.  The book I have recommended a few times, Applying UML and Patterns 3rd Edition by Craig Larman, is an excellent book to learning GRASP and fundamental OOP, which is a good prerequisite to Domain-Driven Design.  Applying UML and Patterns is used as a textbook and hence written in a comforting style that introduces concepts slowly and logically.

Thanks to Jeffrey for his post as it got me thinking even more about how important these basic skills are needed in application design.

This entry was posted in .NET Book Reviews, GRASP Patterns. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

2 Responses to Domain-Driven Design – Layered Applications

  1. Michael Ritchie says:

    Separate UI, Business, and Data layers are a must if you hope to avoid duplicating code and getting any true reuse. Karl Sequin wrote a good article on Business and Data layers over on MSDN ( ). His examples are a good starting point for learning how to build a high quality, multi tier, reusable class library.

  2. Coincidently, I just started reading Domain-driven Design. I look forward to finishing it.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>