Experiences Going From Data-Driven Development to Domain-Driven Design

by Jan Stenberg on Oct 16, 2013 |

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.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

General Feedback
Marketing and all content copyright © 2006-2016 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.