DDD: There Is No Database - Jak Charlton - Insane World. Do not try to bend the spoon; that's impossible.
Instead only try to realize the truth: There is no spoon. The Matrix Again prompted by discussion on the DDD Yahoo list, this post is intended to explain what on the face of it is a pretty dumb assertion – there is no database in DDD! I’m sure right at this point, jdn is reaching for his keyboard to point out that I am dangerously close to repeating The Tao of Domain Driven Design. Yes, I love my mystical analogies! But if you think about this apparently stupid statement, in the context of Domain Driven Design, it has a subtle and important point – DDD is all about the domain, not about the database, and Persistence Ignorance (PI) is a very important aspect of DDD.
What is Persistence Ignorance and Why Does it Matter? Early versions of this were focused on the imaginary requirement that we should be able to change from SQL Server to Oracle with relatively little effort. Where Does Persistence Ignorance Appear in DDD? In Conclusion Previously: DDD: The Repository Pattern - Jak Charlton - Insane World. I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we get to the last major part of the Domain Driven Design picture – Repository.
In traditional architectures, your application talks to some kind of database layer, and asks it to save or retrieve your objects. DDD is slightly different, after all, remember I said “There is no database” Of course, there is a high likelihood you do *actually* have a database, but the Repository pattern ensures you need to take little to no concern of it within your domain. Download the eBook of the series so far … Repository Is Just A Collection The primary thing that differentiates a Repository from a traditional data access layer is that it is to all intents and purposes a Collection semantic – just like IList<T> in .Net Repository Is Just A Facade Repository Is Not A Data Access Layer Well, at least not in the traditional sense – it doesn’t talk in terms of “data” it talks in terms of Aggregate Roots. Strategic Domain Driven Design with Context Mapping. Introduction Many approaches to object oriented modeling tend not to scale well when the applications grow in size and complexity.
Context Mapping is a general purpose technique, part of the Domain Driven Design (DDD) toolkit, helps the architects and developers manage the many types of complexity they face in software development projects. Different from other well known DDD patterns, context mapping applies to any kind of software development scenario and provides a high level view that might help the developers to take strategic decisions, like whether to go for a full scale DDD implementation or not in their specific project environment. In this article we'll explore the many sides of bounded contexts and how to use them in building a context map to support key decisions in a software development project.
Many models at play Domain Driven Design puts a great emphasis in maintaining the conceptual integrity of the model of your application. Figure 1. Enter Bounded Contexts Figure 2.