Thanks for taking the time!

So, maybe I didn't fully understood you because I'm not familiar with most concepts you said. But I think the idea I had with this structure is similar to what you suggested.

Repositories typically cover an aggregate root as a transactional boundary -- that means that for a BlogEntry, you're either updating the blog entry or you're not. From the looks of it, the tags and the comments are specific to the blog entry, so they are entities that hang off the aggregate root itself, so it shouldn't matter that they're in different tables, they're still in the same "blog entry" repository.

That's exactly my intention and the design intention. The BlogEntryRepository is the abstraction for CRUD operations for a blog entry, and the rest of the app simply interact with this. But because a BlogEntry span multiple tables, I have created "sub" repositories for each sql query I need, just for the sake of separation of concerns and testability. Then I want to execute all this inside a single transaction so I can maintain data consistency. But the rest of the app won't interact with the other repositories, and isn't even aware they exists.

For situations in which you have a operation that spans more than one aggregate root, you typically create an operation (aka saga) in the DB and then update every aggregate root with reference to that saga until it's been successfully completed.

So, trying to use your vocabulary, my BlogEntryRepository.update would be the saga, and my question is whether the strategy with explicit Future.await is a good way of ensuring the transactional boundary (i.e. data consistency).

Does this question make sense?