What's a good way to handle entities within an aggregate that persist to multiple databases

I'm dealing with a design problem that I'm sure has a simple answer and/or has been solved before. I've been reading, thinking, and searching for solutions for quite a while, but nothing seems to really make sense.

The gist of the issue is that I'm dealing with a series of legacy systems and databases and I'm trying to take a DDD approach to building new apps 开发者_运维百科and replacing older ones. The core issue is that while my domain entities, value objects, and aggregates make business sense, when I consider persistence I have one big problem... the entities within an aggregate are currently persisted in multiple databases.

For example, let's say I have entities A, B, and C where A is the aggregate root. I have a repository for A and I'm employing the Unit Of Work around an NHibernate session for persistence. All is great and fine as long as A, B, and C are all persisted to a single server/database. In my case, however, A and B might be on one server/database and C might be persisted on a completely different server/database.

I realize that conventional wisdom might suggest that one should never do this, but I'm dealing with a legacy. Sure, in time I'll likely refactor the data tier to something more logical, but for now I'm stuck. I suspect that I'll always have this problem to some degree and I can't help but to think that others have crossed this bridge.

In short, I have a homegrown framework in C# consisting of Fluent/NHibernate for persistence, Unity for IoC and employing standard (or at least recognizable) Repository and Unit Of Work patterns. As for databases, I'm dealing with MS SQL Server and Oracle.

Any thoughts?

Aggregate root shouldn't live across multiple databases.

Greg Young talks about this same issue here.

Something like this is what You should be doing.