Leveraging DDD in Core-Business Applications Using Entity Framework

| by Jan Stenberg Follow 34 Followers on Nov 30, 2013. Estimated reading time: 1 minute |

Domain-Driven Design, DDD, is all about the domain, not about persistence, Julie Lerman recently explained in a presentation at Øredev, a developer conference in Sweden.
Julie, a Microsoft MVP since 2003, working as a consultant on the .NET platform, has been focusing on database programming for 25 years, later years using Entity Framework, (EF), but is now inspired by DDD with its focus on the domain.
Her experience is that a lot of people working with DDD ignore persistence; the database becomes an afterthought at the end of development. But still, in the long run you have to get data into a database and even if Julie focuses on the domain she early on want to make sure that when the time comes to add persistence it will work.

Bounded context is for Julie one of the most important concepts in DDD. Instead of thinking about everything in an application at the same time, entities, behaviour, etc., bounded context helps her thinking about the problem in a more structured way, in subsystems. When working in customer service she can ignore interactions with other subsystems, e.g. marketing. There may be a need for an identity or a small piece of information from another context but for the most part this is bounding things within a contextual domain. This means she can focus on a smaller amount of entities at a time when thinking about persistence.
When working with the same entity, e.g. a customer, in different contexts she redefines the customer entity in each context although they are all still persisted into the same Customer table. A potential extension she sees is to completely separate the contexts by using different tables, or even databases.

Value Objects has been a confusing concept for Julie. She has heard five different explanations from DDD experts, they have all been correct and they have all enriched her view. Now, a value object for Julie is an immutable object without an identity that functions as a complex type persisted over several columns in a database.

Normally Julie uses the domain model also as a data model but in some very complex domains she has found a need for a separate persistence model, one scenario for this is when working with legacy databases.

Earlier this year Julie wrote three articles about her lessons learnt moving from data-driven development into using DDD.

Rate this Article

Adoption Stage

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


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

Recover your password...


Follow your favorite topics and editors

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


More signal, less noise

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


Stay up-to-date

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