Chapter 8. Infrastructure for Persistence

Where are we? We have built a Domain Model from the ground up, and it's in DDD [Evans DDD] style. So far, I've been pushing like crazy for delaying the decisions about infrastructure as long as possible. Sure, we did talk quite a lot about how we could prepare for simplifying the infrastructure addition in Chapter 6, "Preparing for Infrastructure," but now is the time to add the mechanics for supporting the Domain Model: the infrastructure. We will also make some modifications to the Domain Model we have been discussing as the answer to the feature list first mentioned in Chapter 4, "A New Default Architecture."

Important to note is that we will do this because we have to, not because we want to. That's not the same thing as saying it's not important. It's just that we want to put as much of our efforts as possible on the domain problems.

But before we start discussing the infrastructure, the obvious question is what infrastructure is needed? As a matter of fact, a great deal of infrastructure is needed, such as infrastructure for

• Authorization

• Integration (service requests and responses)

• Data management and access (persistence)

• Presentation (which might be a stretch to call that infrastructure)

• Logging

And so on, and so forth. I guess it might be my background as a database guy that makes me see it this way, but I think persistence is the most obvious and interesting infrastructure. At least this is what we will be focusing on in the upcoming chapters.

As we define the needed infrastructure for persistence, we will also make small changes to the current Domain Model design here and there in order to make it fit the typical choice of persistence infrastructure better.

Note

A design approach that does not use iterations is very dangerous. Let's assume that you are responsible for nothing but the Domain Model and the persistence. Even so, you should work a little on the Domain Model, choose and try the persistence infrastructure, work on the Domain Model, check the persistence infrastructure, and so on. This is especially how you should proceed with your first couple of DDD projects, but is always a good idea to some extent.

Let me also clarify that I totally understand that the UI, for example, is extremely important and that it might be considered an insult to talk about it just as "mechanics." Of course I (and the users) extremely value a usable UI. It's also frequently the case that much of the total project time is spent on the UI. With that said, our focus here is the Domain Model. Discussing good UI design is not the purpose of this book (although there is some coverage in Chapter 11, "Focus on the UI").

We have decided to focus on persistence infrastructure. The next question then is what requirements do we have on the persistence infrastructure for being a persistence infrastructure that enables us to focus on the domain?