I’ve mentionned DDD in the previous post, this post is me drafting publicly my thought on the design patterns generally associated with it. this is a work in progress.
Even if not doing Domain Driven Development, the design patterns usually used by the DDD people are something that can benefit a lot of project. To start learning more about design pattern, “Patterns of Enterprise Application Architecture” by Martin Fowler 1 is a must read. If you can’t afford the book, then go steal some money (just kidding) or start by reading the free short summary of each patterns available on the author’s website 2.
Domain Models are a representation of the data, they represent nouns in you domain, such as User or Invoice. As the domain model contain the business logic, it should be the most important part of the code, thus it need to be easy to understand, easy to modify and easy to test. That’s why they should have no external requirement, no knowledge of the external world, avoid tight coupling at all cost.
Domain models contains the business logic (verbs), mainly in the Entity and Repository, and some in the service layer (if, and only if the functionality does not apply to an entity in particular, reference others object of the system, and is stateless. (ex1: $shippingService->calculateShippingCost($zipcode). this does not belong in the Cart Entity because of the dependency on external object such as shipping company API).
Entities should be totally standalone, they should not be aware of repository or anything else.
Entities and Repositories does not write directly to a database or web service, a database layer is usually used such as ActiveRecord or DataMapper. But, writing an activeRecord of dataMapper layer is a long and difficult job, and it’s generally a better choice to use an existing one, especially because of the fact that this layer contain no business logic, there is not a big Return On Investment on building our own.
Some part of the application might seems like Entity but are in fact Aggregate. Some object can’t exist by themselves, such as OrderDetails, they are Aggregate that are connected to an Aggregate Root Order. This mean that the Aggregate don’t have a repository and if you want to add a row to an order you need to go thru the Order Entity. ex: $order->addDetail(…)
