#1 Lack of intent
You build a system but you do not find out what the intention of the user is. It is visible by domain models that are empty from business logic. There will only be four verbs, CRUD which doesn’t tell you anything about what the user wanted to do. 

#2 Anemic Domain Model
A model that looks and smell like a real domain model, but when you are looking for behavior you can’t find it. You have domain services that becomes transaction scripts on top of your Domain Models. It’s not an anti-pattern but it’s not DDD either. Anemic Domain Models work wells in teams with little OO skills in a simple model, but usually they are bad.

#3 DDD-Lite
Using DDD as a pattern language, you do not define context you just implement patterns. If you are a .NET developer and you are running down this path, stop. You either need to do real DDD or something simpler. The middle road is problematic. DDD-Lite will give you all of the overhead and none of the benefits.

Naming things is really important, the value is not in the domain model. The domain model is only a representation of the ubiquitous language. So if the language is not there, the competitive advantage will not surface.

#4 Lack of isolation
Part of why building domain models are expensive is because we want them isolated from everything else. But without it, there will be abstraction leakage left and right.

Example, We might get back 300 fields in our XML but we are only using two. Our domain model should only have those two.

Another example, UoW is really a infrastructure concern why would you bring that into the domain?. If you have your aggregate boundaries right, you don’t need a unit of work.

#5 Ubiquitous what?
The ubiquitous language is only ubiquitous in a context. If you aren’t using bounded context, you will fail with defining the language. The way to find contexts is to find places where word have different meaning. We need to break things apart and focus on our context boundaries.

#6 Lack of refinement
Most projects do not come back to the domain model and do any refinement. The team learns more about the domain, but do not go back and update the model with the new knowledge. A year down in the project you will be translating the model to the domain experts and the ubiquitous language will be lost.

Since the domain model is a tool to analyze the domain and solve problems, it has to be clean and reflect the level of understanding we have of the domain.

#7 Proxy Domain Expert (Business analyst)
Each level of translation a little more get lost. If we are using a proxy domain experts, what’s really happening is that we have two ubiquitous languages. One from the BA to the real domain expert, one from the BA to the developers. What’s the chances they are the same?

A BA shouldn’t be in the middle, they should work as a facilitator and help developers and the domain experts to communicate and get closer to each other.

Reflections
I’ve been in project where all 7 of these failures has emerged in one way or another. It ties into what Eric Evans have been talking about a lot today and most of SOLID principles. Make sure you have clear context where models make sense and clear separation of concerns and you’ll be in a good starting position.

I also reflect over the fact that most failures are based on communication and the expression of what get’s communicated. So much in software development are really not about technology, but yet as the engineers we are, we try to make it about that.

One of the most puzzling emails Eric have received was one claiming that his book really proved that up front design was important. In large this is a miss conception on how modeling happens. A tremendous amount of knowledge comes from actually implementing the software. You have the most insight at the end of the project. You have the most ignorance in the beginning of the project.

On the other hand Agilistas often declare that modeling isn’t necessary at all which is a miss conception of the importance of modeling. In short, the importance is tied into what your goal is and what you think is important.

Different goals, different requirements on modeling

• If your goal is to just complete the next story, modeling isn’t that important. The span of your focus is just that story and a model doesn’t make sense. A lot of agile has this focus in Eric’s opinion.
• If your goal is to complete a releasable set of stories with an acceptable level of bugs, some modeling will be required. Each story will have it’s own impact on the code and for them to behave well together, there has to be some design and thought.
• If your goal is to deliver a release that the team can continue to extend in the next release, you will need a reasonable amount of modeling and design. First release won’t see a huge difference, but the second release will come out faster.
• If your goal is to deliver a clear and cohesive user experience you’ll need a clear underlying model or it will be really hard to put a well designed user interface on top of it.

Modeling and TDD

With a green bar, TDD will give you A answer. It’s a correct answer, but the question is, is it the best model that delivers the answer? It turns out that finding the right answer is not quite good enough. We need to find the right answer that makes sense to a business person.

DDD and The Agile Process
Eric introduced a modeling sub process that he calls “Whirlpool” which helps in defining when and where modeling happens:

It’s currently a draft and you can read more about it @ http://domainlanguage.com/processdraft/

Reflections
It’s really interesting to see how Eric tackles the ideas that modeling should be done upfront and the agile notion of very little modeling, and doing so with a piece or explained process. I don’t fully grasp what all parts of the process does or fit together, but I for one will follow the progress and try to apply it in my next scrum / kanban project I get into.

This was one of the most rewarding sessions for me. Eric Evans explained what he picked up and learned since he wrote the book, what parts that he realized was more important that he initially thought and what parts had been missing.

A missing building block: Domain Events
Something happened that domain experts care about.

what would make this clearer? A property or an event, what would be easier to hook into? 

In his book, events wasn’t covered at all. In the DDD movement today though Events are carefully explored and popular in expressing things that happens that domain experts care about.  They lead to clearer and more expressive models in that instead of adding more state, communicate that state shift with other objects to other objects. Which in terms open up some architectural options that wasn’t available before.

• Events that representing the state of entities (making the model clearer).
• Decoupling subsystems with event streams. Instead of creating tight coupling between subsystems you just send an event to tell others that might be interested what’s going on.
• Enabling High-performance systems. Evans stated that before he saw what Greg Young did with CQRS and event streams, he didn’t think DDD was suitable for this kind of systems. But with this take, it works.

 

What he learned about Aggregates

Aggregates are there to create a consistent boundary. In the book they are explained as a suitable boundary for transactions, distribution and concurrency. But over the years it has turned out that it’s also suitable to use as boundaries for properties and invariants. Again tying into the message he delivers over and over and over again, there is always more then one model 

Things learned by Strategic design

There are a couple of concepts explained in Strategic Design. Some have turned out to be more important then others, Eric emphasizes that Core Domain, Context map and Bounded Context are really important but Large Scale hasn’t come up to often.

Context mapping on the other hand was much more important then he thought from the beginning. There are always multiple models which we need to accept and focus on the mapping between them instead of trying to make one that fits all. The one thing to remember is to be able to clearly communicate in what context a model id viable and have easy ways to communicate in which context we are talking.

This is where bounded context shines, they describe the conditions under which a particular model applies.

Missing Strategic Design concepts

Partners

Partners work on mutually dependent context in cooperation. This means that you share the responsibility of a context and teams will either succeed together or fail together.

Big Ball of Mud

Sometimes you just have to give up. BBoM is the notion of code in such a bad shape that trying to apply DDD on it doesn’t make sense at all. Michael Feathers talk in length about how to handle these scenarios. Within this boundary I’m not going to do any fancy stuff because it won’t work.

Object – relational

Storage should be handled as a separate context and thus a  separate model. Use the strengths of Relational Modeling and don’t try to fit your objects directly into tables and relations. This makes sense when you think about it, if you represent a piece of data with different models in separate context, why would storage be any different?

Eric also mentioned that the work being put into NoSQL is very interesting for DDD practitioners since storage is just another context, and if that context can be expressed easier and be more out of the way of other context, it’s a good thing.

Reflections

I really liked this talk. Much because it validates thoughts I have (and have imposed on my team) around the “One model to rule them all”. There will always be different representations of a piece of data and Evans confirms this with very convincing rhetoric’s. Especially when it comes to putting the database in a separate context and thinking of it as a boundary.

It was also interesting to hear Eric’s thoughts on events and how they have become a first class citizen in Domain Driven Design. The trend in both design and architecture today is to use anonymous push via events and queues which actually is the driver behind a-not-yet published codeplex project which helps in setting up domain events and / or push things out in integration.

Watch this space for updates on that.