Slicing Persistence Adapters

In the preceding figures, we have seen a single persistence adapter class that implements all persistence ports. There is no rule, however, that forbids us to create more than one class, as long as all persistence ports are implemented.

We might choose, for instance, to implement one persistence adapter per domain class for which we need persistence operations (or "aggregate" in DDD lingo), as shown in the following figure:

Figure 6.4: We can create multiple persistence adapters, one for each aggregate

This way, our persistence adapters are automatically sliced along the seams of the domain that we support with persistence functionality.

We might split our persistence adapters into even more classes, for instance, when we want to implement a couple of persistence ports using JPA or another OR-Mapper and some other ports using plain SQL for better performance. We might then create one JPA adapter and one plain SQL adapter, each implementing...