Chapter 6. Preparing for Infrastructure

It's time to continue the exploration of applying DDD to our problem domain. There is no specific next step, but you may be wondering when I will start dealing with the infrastructure. For instance, we haven't yet made it possible to persist or depersist (materialize or reconstitute) the orders to or from a database. As a matter of fact, we haven't even thought about, let alone decided on, using a database.

This is intentional. We want to delay making this decision a bit longer, at least if we are feeling safe and familiar with existing infrastructural options. If this is our first DDD-ish project, this might not be the case, of course, but let's pretend.

The reason I want to delay the binding to a relational database is that in doing so we will focus on the Domain Model with as few distractions as possible. Hey, I'm an old database guy, so it's OK for me to talk about the database as a distraction. I would never dare to say that if I came from the OO side.

Seriously, I'm not saying that the database interaction isn't important; on the contrary, I know that it is important. But staying away from the database a bit longer makes trying out and exploring both small and large model changes more productive for us.

It's also much easier to write the tests, because changes done in tests won't be persistent between executions. The test executions themselves will also execute much faster, making it much more manageable for the developers to run the tests after each code change.

There are also problems with this approach. I have already said that we assume we have good control of dealing with the probable upcoming database interaction, so this is not where the problem lies. Instead, there's a good chance that you will want to write some UI prototypes early on, not only for your own sake as a way of challenging your Domain Model, but also as a way to dialogue with the customer. If these prototypes have "live" data that the user can interact with, add to, and so on, they will be more useful than what is common for early prototypes.

As you might recall, we ended Chapter 5, "A New Default Architecture," with a preliminary discussion about adding early UI examples. Users will find these examples even more interesting to try out if the data is also around after a restart. (Sure, this can easily be done if you start using the planned persistence solution directly. However, we expect that this will increase the overhead during early refactoring attempts, so what we want is to create an inexpensive "illusion.")

Note

Watch out so that your customer (or your boss) doesn't think that the whole application is done after only having seen one or two prototypes. Been there, done that.

The second thing I'm after at this point is to be able to write tests for save scenarios here, again without dealing with a real database. You might ask what the point of this is. Again, I'd like to focus on the model, the semantics "around" it, and so on.

I could certainly deal with this problem on an individual basis in the repositories, as I have done so far, but I see value in having consistency and just applying one solution to all the repositories. I also want a solution that scales up to early integration testing, and most importantly I want to write real repositories now and not stupid, temporary code that should be thrown away!

So even though I started out saying that it's too early for infrastructure, this chapter will deal with preparation for the infrastructure, and in such a way that we won't have to redo work when we add infrastructure. What we want is to write infrastructure-agnostic code.