Intrigued and inspired by Domain-Driven Design, DDD, but with a long history of data-driven development, Julie Lerman have struggled, argued and whined her way into understanding how to use her skills with DDD. Julie, a Microsoft MVP since 2003, working as a consultant and mentor on the .NET platform, assumes many developers go through the same struggle, which is why she is sharing some of the lessons she have learned in three articles in MSDN Magazine.
Julie emphasises that DDD is for complex behaviours, something not all parts of an application contains. For parts with simple create, read, update and delete, (CRUD), you will probably be better off with a non-DDD implementation, but with a combination of complex behaviour and CRUD, Julie's suggestion is to identify the complex parts and separate these into separate bounded contexts and apply DDD on these areas.
When into DDD and modelling a domain, Julies focuses on the business, working with the tasks and behaviours needed. Data persistence is unrelated to the business problems and should therefore play a supporting role not interfering with the domain design.
One topic Julie have had problem with is sharing types and data across subsystems. In her mind sharing types has been mandatory, including working against the same table in the same database. DDD has taught her that it may very well be OK not to share a domain model and therefore store the same type of data from different subsystem into different tables, and databases. It isn’t a crime to duplicate data; in the long run it may simplify your system by removing the complexity of sharing data.
In her final thoughts Julie looks into some issues when using an ORM tool, in her case Entity Framework. One issue is unidirectional relations, which is the preferred way of association working with DDD. Eric Evans, author of the original DDD book, advice is that “it’s important to constrain relationships as much as possible”. Two-way relationships have been the norm for Julie since starting with Entity Framework. She now finds them convenient but the actual need in the domain is very rare and leaving them out will remove some of the complexities of managing relations.
Julies articles are accompanied by an example written in C# together with Entity Framework, Microsoft’s object-relational mapper for the .NET platform.