Posts Tagged DDD
NDC2010: Greg Young – 7 reasons why DDD projects #fail
Posted by Patrik Löwendahl in NDC2010 on June 17, 2010
#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.
NDC 2010: Eric Evans – Folding together DDD into Agile
Posted by Patrik Löwendahl in NDC2010 on June 17, 2010
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.
NDC 2010: Eric Evans -What I learned since the book
Posted by Patrik Löwendahl in NDC2010 on June 17, 2010
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.
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.
NDC2010: Eric Evans – Strategic Design
Posted by Patrik Löwendahl in NDC2010 on June 17, 2010
In almost every conversation I’ve had with Eric Evans and Jimmy Nilsson and every talk I’ve heard Eric present, the same message have been lifted; “I wish I put part 3 [strategic design] in the beginning of the book”. In this talk he explained why.
Bad strategies
ent on mentioning a few other mistakes people do:
- Building a platform to make the other (lesser) programmers more productive. If they are [lesser] chances are they can’t use the platform anyway.
- Cleaning up other peoples mess. (Invisible value). One irresponsible programmer can keep 5 really good programmers busy cleaning up.
- Rebuilding already working software, delivers visible value, but will it deliver any new sexy value?
- The Enterprise Model
In Eric’s opinion there are really bad consequences for a bad strategy and most of them are tied into information not floating to the surface. He lifted up a really good example where a programmer warns about potential data-corruption that someone else introduced, sits up all night to fix it, and when there is no data corruption; management will turn to the fixer and say “see, no problems you where just crying wolf”.
What’s a responsible designer to do?
In the talk, Eric highlighted three strategies from his book that we should focus on to create a great strategy.
Distilling the core Domain
There is always a reason for building custom software. Something makes it hard to but it off-the-shelve. This is the core domain. This is the difference between what you do and what others do. Sometimes it’s easy to find, other times it’s not as easy. The point is that it’s in the core domain the interesting stuff is happening, where the new sexy features get implemented.
Context Mapping / Bounded Context
For this part the message was clear; “There will always be more then one model”. He gave the example of The Blind Men and The Elephant. Not everyone will look at things in the same way and context is very important.
Anti-corruption layer
This is a strategy where you hide away the bad design with a layer above it that straightens it out a bit, build your new features on top of that piece.
Good Strategic Goals,
A picture says it all,
Reflections
Strategic design it is my favorite part of Evan’s book. It helps us understand how to look ahead and make sure that our shiny new toy shines all the time. I’ve seen this talk before but it’s like the book, every time I see it there is a new point made that I didn’t thing about before. This time the focus on the core domain really sunk in and I immediately realized why we’ve hade problems in our current project and in a couple of earlier.
Slice up your business logic using C# Extension methods to honor the context
Posted by Patrik Löwendahl in Architecture, design patterns on February 20, 2010
One of my favorite features with C# 3.0 is the extension methods. An excellent way to apply some cross cutting concerns and great tool for attaching utility functions. Heavily used by the LINQ frameworks and in most utility classes I’ve seen around .NET 3.5 projects. Some common example usages I’ve come across include:
1: var name = "OlympicGames2010".Wordify();
2: var attributeValue = typeof(Customer).Attribute(o => o.Status)
3: .Value();
Lately I’ve started to expand the the modeling ideas I tried to explain during my presentation at Öredev 2008. It became more of a discussion with James O. Coplien then a presentation and I was far from done with my own understanding of the ideas and issues I’d identified (there are things improve in this content). The core idea is pretty simple though:
Not all consumers of an object are interested of the same aspects of that object, it will take on different roles in different contexts
Let me explain with the simplest example; when building an order system, the aspects of a product that the order think is important are usually not exactly the same aspects that the inventory system value.
Contexts in object models
Eric Evans touches this in his description of “bounded contexts” (Domain Driven Design p335) where he stresses the importance of defining contexts where a model is valid and not mix it into another context. In essence the model of a product should be duplicated, once in the order context and once in the inventory context.
This is a great principle but at times it be too coarse-grained. James Coplien and Trygve Reenskaug have identified this in their work around, what they call, “DCI architecture”. Richard Öberg et al have done some work in what they call qi4j where they are composing objects with bits and pieces instead of creating full blown models for each context.
Slicing logic and models using Extension Methods
Let’s get back to the extension methods and see how they can help us slice business logic up in bits and pieces and “compose” what we need for different contexts.
In the code base I’m writing for my TechDays presentation I have a warehouse class that holds stock of items. These Items are common for different contexts, they will surface in orders and PLM. One of the features in this application is to find a stock to reserve a given an item. The following code is used to find that stock:
1: return Stock.First(stock => stock.Item == item);
Although trivial, this is a business rule for the warehouse. When the warehouse class evolved this piece of rule would be duplicated in methods like Reserve, Releaes and Delete. A classic refactoring would be to use Extract Method to move it out and reuse that piece, something like:
1: private bool Match(Stock stock, ItemInfo item)
2: {
3: return stock.Item == item
4: }
5: ...
6: return Stock.First(stock => Match(stock, item));
This is a completely valid refactoring but honestly we loose some intent, the immediate connection with stock and item are not as explicit and the lambda expression wasn’t simplified that much.
So let’s Refator to Slice instead:
1: public static class ItemInAWarehouseSlices
2: {
3: public static bool Match(this ItemInfo @this, Stock stock)
4: {
5: return stock.Item == @this;
6: }
7: }
Adding this business rules as an extension method gives us a natural place for the code to live and a mechanism to use to compose objects differently in different contexts. Importing this extension method class into the Warehouse C#-file, ItemInfo will provide the logic needed in that context;
1: return Stock.First(item.Match);
Adding the rule this way also sprinkles a touch of DSL on it and gives it a semantic meaning which makes the code make more sense.
Why don’t you just put that method on the ItemInfo, you migh ask. Well the answer is simple. ItemInfo is a concept that might be shared across contexts. Contexts that have no grasp of what a Stock is, nor should it. If I’d add everything I needed to the ItemInfo class for all contexts that uses Item. I would be in a bad shape. Thus the ideas behind Contextual Domain models, Bounded Context, DCI and Composite objects.
Extend away …
So extension methods have other usages then just extending existing classes with some utility. It’s also a powerful tool to slice your logic in composable pieces which helps you focus on the aspects you think is important in the current context you are working.
So what do you think? Will this help you create clear separtions?
