Basically this is a principle. that uses the common practice pattern and incorporate existing OOD,Gof,Solid,TDD etc.
the substance difference is we want to keep the Domain Clear and not Interfere by other . we want to keep Domain readability , and separate from other.
I find it’s a bit hard to understand at first.
To see it in action and a glimpse,
- i read a chapter about this on Asp.net MVC 2 in action.
and after this to further have deeper insight,
I’ve got to read the Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans, kind a lost here what a abstract book, found a better one
- Read Domain Driven Design Quickly , it’s only 106 pages. I’ve read all of it and really grasp the theoretical concept. but to make it correctly or at least follow the true separation on the real world?? See the Example Project , and here
- More to read
- And to really give you guidance it’s the .Net domain Driven Design with C# , Wrox. Currently I’m reading it.
DDD will shine on Complex domain project
About the Application Layer , What it should do? as i guess from the very start it’s almost a Facade. which will be used by Presentation Layer
“I would like to approach the application layer as an application programming interface (API), or almost
a fa ç ade, to the domain model. The reason I say almost a fa ç ade is because the application will be doing a
little bit more than just making it simple to use the domain model; it will also be coordinating actions
between different domain objects as well as maintaining the state of a particular task. The classes in this
layer will be composed of mostly static methods, thus making it easy for a class in the presentation
layer to do some work. An example is having a ProjectService class in the application layer that has
very simple methods to load and save a Project, such as Project.GetProject(1) and Project
Active Record pattern is ideal to used when 1:1, and have few operation. on Active Record the Persistence is on the model.
while on DDD the Persistence is on Service Class.
Some People use UnitofWork when they use Hibernate,and EF to track changes.
while for Linq to sql it’s already a single unitofwork per instance of dataContext
“The DataContext conforms to the Unit of Work design pattern. Unless you are moving data between physical tiers between each operation you should keep your DataContext alive for the duration of work.”
Aggregate is an entity which can stand by it self
Value Object is an entity which won’t be exists if there is no aggregate
Aggregate Root is the root which define a boundary between aggregate, all value object may not have direct reference to another Aggregate root
Repository, all persistence and load existing object must use repository. any need for direct link without going to aggregate should use repository
Factory, any creation of object should use factory method or if too complex use factory class
Service, any operation that involve more than 1 entity and operation does not belong to certain entity should use service
Specification, any constraint and validation should use specification
I’ve seen some sample that doesn’t use the Application Layer at all, what distinguish domain layer and application layer?
on some of discussion Link, it is said by udi dahan that application layer is “workflow layer” or “process layer”
if your application in need a certain WorkFlow to interact and coordinate with other layers, than application layer is fit this.
Application is something anything that is high level for your application to run, session.
Create Immutable with readonly property on .net.
Domain Event :
The essence of a Domain Event is that you use it to capture things that can trigger a change to the state of the application you are developing. These event objects are then processed to cause changes to the system, and stored to provide an Audit Log.
Even though all the domain specific business rules should be encapsulated in the domain layer, some application designs put the rules in facade classes, which leads to domain classes becoming "anemic" in terms of business rules logic. This may be an acceptable solution in small size applications, but it is not recommended for mid-size to large enterprise applications that contain complex business rules. A better design option is to put the rules where they belong, inside the domain objects. If a business rule logic spans two or more Entity objects, then it should become part of a Service class.
Entity, Value Object, Aggregate
State and Behavior
Data Transfer Object
How to Differentiate entity and object Value?
if found that it can be answered by this question:
If two instances of the same object have different attribute values, but same identity value, are they the same entity?