Frameworks and DDD: Keeping the Model Clean

How to avoid pitfalls and preserve a clean domain model while using frameworks. 

Tim McCarthy is is the author of .NET Domain-Driven Design with C#: Problem-Design-Solution

View presentation at InfoQ

Application Layer [Service Layer]: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.

Domain Layer (Model Layer): Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software.

From Eric Evans' Doman Driven Design, via Fowler's Anemic Domain Model

Eric Evans - DDD Videos

Eric Evans on Domain Driven Design

Presentation by Eric Evans: Making Models Work First part

Presentation by Eric Evans: Strategic Design Second part

Pragmatic Programmer on DDD

Program Close to the Problem Domain

Design and code in your user’s language.

Steve Eichert on DDD: Factories and repositories

By separating the responsibilities of data retrieval into our Repositories, and object creation into our Factories we allow our domain objects to stay focused on representing the domain. We also allow our applications to become more de-coupled which allows us to more easily test our applications.

Eric Evans on DDD

Now I am focused on making sure my consulting clients get their money's worth from their software development efforts by focusing on their core domain, effectively expressing that model in their software [-]

A software project should be a voyage of discovery that a team of software experts, domain experts and business strategists all take together. A team like that can collaborate to chart a course to a very valuable destination that is not entirely known at the outset.

Domain Driven Design @ CodeBetter

Domain Driven Design @ CodeBetter