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.