BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

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

| by Jan Stenberg Follow 6 Followers on Oct 16, 2013. Estimated reading time: 1 minute |

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

Adoption Stage
Style

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

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT