-
This past week, I attended a presentation on Object-Role Modeling (with the unfortunate acronym ORM) and its application to DDD modeling". The talk itself was interesting, but more interesting were some of the questions from the audience. The gist of the tool is to provide a better modeling...
-
Previous posts in this series: A Primer Aggregate Construction One of the common themes throughout the DDD book is that much of the nuts and bolts of structural domain-driven design is just plain good use of object-oriented programming. This is certainly true, but DDD adds some direction to OOP...
-
Our application complexity has hit its tipping point, and we decide to move past anemic domain models to rich, behavioral models. But what is this anemic domain model? Let’s look at Fowler’s definition, now over 6 years old: The basic symptom of an Anemic Domain Model is that at first blush...
-
Recently, I talked some about the idea of an intentionally anemic domain model, under the name of “ Persistence Model ”. While a Persistence Model is great for a large percentage of projects, you may eventually want to move more behavior into the domain. That doesn’t mean a bevy of domain...
-
Last night, I had a Skype/SharedView session with a buddy in Arkansas trying to apply DDD and “best practices” to an application he was building. He wanted to use all the ALT.NET tools he’s heard so much about, such as NHibernate, StructureMap and so on. The problem came when he went to go...
-
Domain anemia is a term thrown around like it’s a horrible disease. However, a while back, Greg Young talked about an intentional decision to create an anemic domain model . In some contexts, an anemic domain model is an anti-pattern . Instead, I see a rather different issue going on...
-
Looking at the different Repository pattern implementations, one thing really surprised me – how far off these implementations are from the original Fowler definition of the Repository. Instead, we see a transformation to the examples in the Evans description of Repository. Fowler’s definition...
-
One of the major structural patterns encountered in DDD (and one of the most argued about) is the Repository pattern . You’ve created a persistent domain model, and now you need to be able to retrieve these objects from an encapsulated store. In Fowler’s PoEAA, the Repository pattern is described...
-
It’s a common question, “Where do I put validation?” Simple answer: put it where it’s needed. But it’s not just a question of “where”, but of “when”, “what” and “why”. If we treat our entities as data holders, we might think to put all of our validation there, in the form of reactive validation...
-
In my last post, I went on a long-winded rant on how the composition and the Aggregate Component pattern can ease the burden of the interaction between Entities and Services. The question comes up often on DDD or IoC forums: How do I inject/use a Service/Repository inside an Entity? You can get...
-
Domain-Driven Design can help focus development efforts into crafting a strong, expressive domain model. In Evans’ book, he dives in to a series of patterns which, when combined, form that strong domain model. These patterns include Entity, Value Object, Service, Factory, Repository, Aggregates...
-
The Domain-Driven Design book (or, the Blue Bible), is chock-full of patterns. Software patterns, team patterns, integration patterns and so on. As a consequence, many readers might assume that DDD requires these patterns, that you must apply these patterns, and not following these patterns...
-
One common question when applying DDD is how to interpret other architecture’s concepts of a “model”. For example, two common presentation architectures are MVC and MVP. In each of those acronyms, the “M” is short for “Model”. So what exactly is this Model? Is it the Domain Model...
-
It’s a question I see quite a bit, on the ALT.NET mailing list, the DDD mailing list, and any other medium where DDD comes up. For those trying DDD, this is a rather difficult question to answer. Many have tried to create DDD how-to’s and samples, including Jimmy Nilsson in his book . ...
-
Services are first-class citizens of the domain model. When concepts of the model would distort any Entity or Value Object, a Service is appropriate. From Evans' DDD, a good Service has these characteristics: The operation relates to a domain concept that is not a natural part of an Entity or Value...