http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Oren, that is a fairly well thought out critique of the idea, I've tried to respond here: http://www.base4.net/blog.aspx?ID=566 Cheers Alex http://ayende.com/2752/data-layer-componentization#comment6http://ayende.com/2752/data-layer-componentization#comment6Mon, 03 Sep 2007 11:14:56 GMTRoy, thanks, I removed the duplicated. http://ayende.com/2752/data-layer-componentization#comment5http://ayende.com/2752/data-layer-componentization#comment5Sun, 02 Sep 2007 10:06:14 GMTBy the way, Oren, you double-posted this one. And I don't think I would ever implement this Data Layer Componentization thing. I might do a cluster, or MySQL log following. If I was FORCED to split my data across databases where commonly resolved relations crossed the boundary, I would try to keep a local read-only copy for fail-over if/when the other database needed to be cycled. This would be "fun" to test, and testing the failures would be VERY necessary. Referring to Alex's blog entry, he mentions data duplication across databases within a company. This can be VERY true, and every piece of data should have ONE master source. This is a hard problem to solve when 3rd party apps are involved, and Payroll, Human Resources, and Customer Data Management are 3 different apps on different databases, with little or no direct db access available. If I had my choice, I would go for simplicity where possible, and limit complexity with the one master source principle. http://ayende.com/2752/data-layer-componentization#comment4http://ayende.com/2752/data-layer-componentization#comment4Sun, 02 Sep 2007 06:23:57 GMTWhy bother. Keep things as simple as possible. When you start abstracting you have to dig deeper and deeper to fix things, because it's not obvious what's going on. Oh yeah, of course it's faster programming with abstraction - until things break. I'll take simple is best and program the pants off of an abstractor anyday, both coding, testing, debugging, and maintaining. So I say no to tangling all the databases together. What snot. http://ayende.com/2752/data-layer-componentization#comment3http://ayende.com/2752/data-layer-componentization#comment3Sun, 02 Sep 2007 01:33:03 GMTI was just thinking that the "to query" part of my last comment was a bit misleading.. Use the master silo for that entity to invoke business processes for that entity (ie.. CancelOrder) Evan http://ayende.com/2752/data-layer-componentization#comment2http://ayende.com/2752/data-layer-componentization#comment2Sat, 01 Sep 2007 22:56:02 GMTMainDB will also suffer concurrency problems (assuming there is data contention and transactions). Share data at the logical layer, not the physical layer. This means putting services in front of those entities (not the CRUDy kind, the kind with behavior). Here's a good maturity model: http://blogs.msdn.com/nickmalik/archive/2007/08/14/a-maturity-model-for-data-integration.aspx Build the silo, define data ownership among silos, determine the common business process event model (and common logical data model), then integrate using it. The events allow the "silos" to keep data in sync (think pub/sub). Duplication of data across silos is ok as long as there is a master somewhere (ie.. to query). Use idempotence of the message schema to mitigate concurrency problems.. Hope this helps (in a nutshell)! http://ayende.com/2752/data-layer-componentization#comment1http://ayende.com/2752/data-layer-componentization#comment1Sat, 01 Sep 2007 18:11:42 GMT