Transactional DB operations without violating domain driven design

For the sake of explaining, let’s say we have a books collection and a pages collection!In domain driven design, one might split handing book meta data, e.g author, title, cover images, etc into one domain, and pages into another. As both clearly have their own set of responsibilities.If we are cloning a book, we need to ensure that every single page and the parent object itself, e.g the book, are all cloned and inserted into the database. If one of these operations fail, everything needs to be reverted (which a transaction would automatically handle!)However, if the infrastructure layer for the books collection and the infrastructure layer for the pages collection don’t know about each other... there is no way to handle this kind of case without programming it yourself. Even in the case, you risk corruption if your application crashes.How do you execute on something like this, while keeping your business logic and various layers isolated to improve code quality.Thanks!Edit: coming for the assumption that you might handle a book update/insert and a page update/insert in separate contexts

Submitted July 20, 2020 at 12:30AM by grumpyrumpywalrus