DDD: persisting domain objects into two databases. How many repositories should I use?

Question

I need to persist my domain objects into two different databases. This use case is purely write-only. I don't need to read back from the databases.

Following Domain Driven Design, I typically create a repository for each aggregate root.

I see two alternatives. I can create one single repository for my AG, and implement it so that it persists the domain object into the two databases.

The second alternative is to create two repositories, one each for each database.

From a domain driven design perspective, which alternative is correct?

Answer 1

My requirement is that it must persist the AR in both databases - all or nothing. So if the first one goes through and the second fails, I would need to remove the AG from the first one.

If you had a transaction manager that were to span across those two databases, you would use that manager to automatically roll back all of the transactions if one of them fails. A transaction manager like that would necessarily add overhead to your writes, as it would have to ensure that all transactions succeeded, and while doing so, maintain a lock on the tables being written to.

If you consider what the transaction manager is doing, it is effectively writing to one database and ensuring that write is successful, writing to the next, and then committing those transactions. You could implement the same type of process using a two-phase commit process. Unfortunately, this can be complicated because the process of keeping two databases in sync is inherently complex.

You would use a process manager or saga to manage the process of ensuring that the databases are consistent:

1. Write to the first database and leave the record in a PENDING status (not visible to user reads).
2. Make a request to second database to write the record in a PENDING status.
3. Make a request to the first database to leave the record in a VALID status (visible to user reads).
4. Make a request to the second database to leave the record in a VALID status.

The issue with this approach is that the process can fail at any point. In this case, you would need to account for those failures. For example,

• You can have a process that comes through and finds records in PENDING status that are older than X minutes and continues pushing them through the workflow.
• You can can have a process that cleans up any PENDING records after X minutes and purges them from the database.

Ideally, you are using something like a queue based workflow that allows you to fire and forget these commands and a saga or process manager to identify and react to failures.

The second alternative is to create two repositories, one each for each database.

Based on the above, hopefully you can understand why this is the correct option.