New York City has been a great place to do this training course. The training facility is located downtown on the 31st floor of a building overlooking Battery Park, Ellis Island and Lady Liberty.
I felt a little intimidated coming all the way to a huge city like NYC, but there really is no good reason for feeling that way. In terms of accomodation, hotels are plentiful, and there are ones catering to every taste and budget.
Transport-wise, it has been fun riding the subway each day from the West Village to 1 Water St (a 7 minute walk from the Jane to the Subway, and then a 15 minute train-ride which drops me right outside the building).
DDD Immersion Course - Blog Series Summary
Here are links to the entire series:
- Part One – Introduction. What is DDD? Ubiquituous language? a Model?
- Part Two – Building-Block patterns (eg. Aggregate. Domain Event. Creative Collaboration etc)
- Part Three – Strategic design – Bounded Context and context mapping.
- Part Four – Strategic design (continued) – Core Domain
- Part Five – More on supple design (Specification pattern). Implementation concerns. Discussion.
- Part Six – Design and agile.
- Part Seven – Final. Course takeaways and other thoughts.
Day 1 (cont.) & Day 2
On Day 1 and 2 we focused primarily on tactical design considerations, whereas days 3 is concerned with strategic design.
We worked through the regular DDD building-block patterns such as Entity, Value Object, Aggregate and Repository. This was done through a series of case studies, group brainstorming sessions (at flipcharts), and pair coding exercises. The exercises were in Java, but working with the code and using Eclipse and JUnit were not an issue for me and the other .NET developer. These coding exercises were particularly significant for me in terms of understanding Value Object immutability and supple design techniques such as closure of operations.
Aggregates are consistency boundaries, and are always internally consistent. Invariants apply at every transaction commit. They may be inconsistent at varies times amongst each other.
Guidelines to 1st-pass aggregate boundaries
Note that finding Aggregates is not just a technical issue, it also relates to finding meaningful conceptual groupings. Object instance diagrams (as opposed to class diagrams) can be especially helpful in seeing these conceptual groupings.
Eric commented that generally the technical people have taught the business people the need for transactional consistency, and that it’s not bad to unlearn this when it comes to inconsistencies across Aggregate boundaries. So we define consistency boundaries (i.e., around each Aggregate), then have some mechanism for updating them asyncronously. However, as the notes above say, things within the boundary must be 100% consistent. This leads to the conclusion that all of an aggregate must be on one node of a network. And, optionally, different aggregates can potentially be on different nodes of the network.
You can't hold a reference to an object in the aggregate root, only to the root. However, the important thing about aggregates is consistency, not so much access. The rules about access are not the fundamental thing.
The requirement for internal consistency means that we must validate the entire Aggregate at the commit time. Here are some things I thought were really interesting and helpful to me:
Sometimes it may be appropriate to create a separate object to represent an Aggregate. It may have properties such as total and validate. You may need to allow it to have the kind of access that repositories can have (allow database queries). In this case the Aggregate root does not have to have responsibilty to calculate it, but can delegate to a repository to retrieve it instead.
Repository is about an Aggregate, not about an object. This is an important distinction between repositories and DAO's.
Sometimes we tend to underspecify our models. Eg. draw a class diagram and leave it there. Or, alteratively, we may tend to overspecify our models too – where our descriptions of models are actually descriptions of implementations.
We really care that the integrity of the aggregate is enforced, and the properties we care about. If you really need to put it somewhere else then at least keep it in the domain. None of the existing frameworks or languages support this very well.
We also covered the Domain Event pattern, which is a newer building-block DDD pattern that Eric has added to DDD since the DDD book was published.
What do we do with domain events?
I know I’m neglecting to mention a lot of things here, but you’ll just have to bear with me (oh, and attend the course to fill in the gaps!).
On Day 2 we watched a series of professionally-produced videos of interactions between a domain expert and developers to illustrate various aspects of what it takes to have a creative collaboration between domain experts and the development team. I could really relate to the situations depicted in the videos, and learnt a lot from the discussions.
Continue to Part Three – Strategic design – Bounded Context and context mapping.
Go back to Part One – Introduction. What is DDD? Ubiquituous language? a Model?