News Archive
PhpRiot Newsletter
Your Email Address:

More information

Domain-Driven Design Immersion Class

Note: This article was originally published at Planet PHP on 2 October 2010.
Planet PHP

I just wrapped up a four day Domain-Driven Design Immersion class with Eric Evans (author of Domain-Driven Design) and Paul Rayner. The class was put on by Eric's company, Domain Language. If you're looking for training or consulting in Domain-Driven Design, I highly recommend that you get in touch with them. I'd like to share some highlights of the class here.

Putting the Model To Work

Domain-Driven Design is a set of three guiding principles:

I should point out that the word aoModela has many different meanings in software development. Within Domain-Driven Design a Model is a aosystem of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.a Those familiar with the Model-View-Controller (MVC) pattern should note that the word aoModela within the MVC pattern has a different meaning than aoModela within Domain-Driven Design. Within Domain-Driven Design a Model is a conceptual tool used to understand a Domain. An example that was used in the class was the game of baseball. A Model of the baseball Domain would include concepts such as strikes, balls, and outs. The classes and objects representing these concepts would not be the Model.

You might be wondering what the difference is between the Domain and the Model. The goal with Domain-Driven Design is not to create a Model of reality. Even if you could come up with some objective view of reality this would not be very useful. Instead, we are trying to understand (and perhaps develop) the Models that Domain Experts already use to understand the Domain. It's important to note that Models are only useful for a particular purpose. What are you trying to do with this Model? Trying to use a Model designed for a different purpose will lead to a less than optimal outcome.

The Model Exploration Whirlpool might be a useful reference if you're looking for concrete guidance on how to explore Models, especially in an Agile or Lean setting.

Building Blocks

Group Entities and Value Objects into Aggregates. Entities are objects defined by a thread of continuity and identity. Their only responsibilities should be around identity and life cycle. Within a customer relationship management (CRM) system a person would likely be an Entity. Note that context matters: a person in another context may be a Value Object. A Value Object aois an object that describes some characteristic or attribute but carries no concept of identity.a Using the CRM example again, a phone number might be a Value Object. Again, context matters: if you're a telephone company then a phone number may very well be an Entity. Treat Value Objects as immutable. Delegate business logic to Value Objects, identity and life cycle are plenty of responsibility for Entities. Grouping these Entities and Value Objects into Aggregates is useful when defining transaction, distribution, and concurrency boundaries.

An interesting topic covered in the class that I don't believe was in the book was the idea of Domain Events. A Domain Event is something important that happens within the Domain that may lead to a state change in a domain object. Instead of keeping track of the current state of an Entity, you can instead compute this state from the currently known Domain Events. Using a baseball analogy again, a Domain Event might be a strike. Domain Events can trigger other Domain Events: three strikes triggers an out. The current state of the game can be computed from all of the Domain Events.

Supple Design

Since this has been a topic of conversation here on my blog and on Twitter, I plan on writing another blog post on why Value Objects need to be immutable. However, I want to point out here that if you think you need to change the state of a Value Object then instead have a me

Truncated by Planet PHP, read more at the original (another 3258 bytes)