We are trying the Domain Driven Development (DDD) while working on a project.
We’ve got a Product aggregate.
We’ve got a ProductRepository to load/save Products.
We’ve also got a Timeline aggregate, that contains TimeLineItems. And there’s a TimelineRepository.
When a product is created/changed, we have to add a TimeLineItem to the Timeline aggregate, like a logbook that logs the changes.
The total process of creating a Product and saving a TimeLineItem to the timeline, could be considered as one transaction (am I right?).
Because, the whole transaction should either succeed entirely, or fail entirely. We don’t want to have a product in the database but no timeline item saying it was created and vice versa.
In DDD, an aggregate root has its repository. There’s ProductRepository and TimelineRepository. We have to interact with both to finish our task.
I don’t want to confuse the concept of transactions in DDD with a transaction in database terms. By this I mean when we’re using Laravel, we do something like:
try {
DB::beginTransaction();
// Do something
DB::commit();
} catch(...) {
DB::rollBack();
}
When we’re in a repository and we have to work with multiple database rows or tables, we can wrap that in a transaction like that piece of code. Because its packed together in the same class or even the same function. The world outside of the repository doesn’t have to know and it’s specific to the storage technology (in this case a database).
But when we have to interact with two different repositories, we cannot “share” that transaction.
-
Because the repositories can both use a different storage technology. Say that the
ProductRepositoryuses a database and theTimeLinerepository a file or some kind of cloud service. When the transaction (DB::...) fails, it has effect on the database, but does not rollback anything in a file or cloud service. We have to implement that mechanism ourselves. -
If both repositories use the exact same storage (like both one and the same MySQL database), we still are not allowed to do something like:
.
try {
DB::beginTransaction();
$productRepo->save($product);
$timelineRepo->save($timeline);
DB::commit();
} catch(...) {
DB::rollBack();
}
How do we solve this problem?
3
How do we solve this problem?
You’re going to have to relax some of the constraints that are getting in your way.
When a product is created/changed, we have to add a TimeLineItem to the Timeline aggregate, like a logbook that logs the changes.
My best guess, based on what you’ve written here, is that the constraint that you should drop is the idea that this timeline is a separate aggregate that you keep immediately consistent with the Product changes.
(TimeLineItem really doesn’t sound like it’s taken from the language of the business, which is why I’m most suspicious on this point).
Based on the description above, I would expect that you are looking for a pattern like DomainEvents – as part of storing the updated product aggregate, your are also storing messages as rows in some table. All of the information you need is captured when the transaction commits, and further processing can happen later (in other transactions, if necessary).
(In the extreme version, the sequence of domain events becomes the authoritative representation of the product aggregate. See: event sourcing.)
In the rarer case where you really do have two aggregates, and they need to participate in the same transaction, then you are going to have to incorporate into your “repository” design some affordances to get them enlisted into the same transaction. Depending on what capabilities in your implementation language of choice, that might mean your repository supports two interfaces: one with affordances for transaction management, another for the actual illusion-of-an-in-memory-collection affordances.
This gives us some of the benefits of the repositories being opaque, while still allowing the useful work to be done.
Leave transaction control to the client. Although the REPOSITORY will insert into and delete from the database, it will ordinarily not commit anything. — Eric Evans: Domain Driven Design (chapter 6).
In the case where you have two aggregates participating in the same transaction to ensure immediate consistency, AND you are using two completely different storage solutions for those aggregates….
This will usually mean that someone made an error in the design of the system, and the correct thing to do is figure out which error was made, thereby replacing the current problem with one that is easier to solve.
(Separating transactional data into separate storage solutions opens up a bunch of exciting failure modes; in the best case, solving those failure modes is expensive….)
1