POCO design question

Question

Can/Should my POCO's encompass multiple Databases if applicable?

The reason I ask is that I am in the process of refactoring a legacy Enterprise App that was built in stages. Unfortunately, each stage had it's own separate DB (at least they are all on the same SQL instance).

Because of this I can easily see where a typical Business Object could cross over between the 2. I know that in DDD my object shouldn't be aware I just wondered if there was a, kind of, unwritten rule that multiple tables were fine but not multiple DB's.

Will this cause me massive headaches down the line, i.e., should I put energy into merging the 4 separate DB's into 1 since they all apply to the same app versus applying a "band-aid" solution?

Take any statements I made with a grain of salt as I am teaching myself Domain Driven Design as I do this and attempting to apply it as I go.

Answer 1

Your POCOs should be Persistence Ignorant - they don't care where they came from, or where they're going to.

Your focus should be on Respositories: they define where data comes from, and how that data is injected into your POCOs. When you decide to consolidate your databases, you should only need to update your Repository classes.

Hope that helps.

Answer 2

Our current in-house system uses multiple databases. Our customer data comes from an off-the shelf ERP. Our "shopping cart" data comes from several custom databases that are broken up into products and quotes. Once we interface with accounting/shipping we'll be connecting to yet another database to access orders data. Sometimes there are views within our site that aggregate information from all of these systems so our POCOs get filled up with all kinds of gunk originating from places far far away. We leave it up to our domain service layer to access the various DBs and fill up our POCOs.