Domain driven design, as it has been explained to me, dictates that the data shall have the truth in the domain model layer at the same time as you must have a bounded context.
This way you create an information Island bound on the application layer!
The integration work between these systems, as they grow in fast iterations (say Scrum-sprints) will surely be huge, and the "single version of the truth" across the value chains will be a distant dream, evens when it comes to central dimensions like "Customer" and "Product"!
Will be exciting to see the solutions to this, so far I have heard
- Shared Kernel
Well... you need it in the database to solve all the integration points, you can't expect ETL and EAI to use an application layer that changes all the time, you want access to the databases in most cases. Many reasons for that across scalability, security, ease of implementation and testing etc
- Anticorruption Layer
Well, in a siloed system this would in my mind include context tables on every single shared entity, which I haven't really seen samples of yet, I expect this is not thought through. Might be promissing.
- Explicit model delimination
I didn't understand the consept, which tells me that it might be too complex for a simple common problem. The solution shouldn't be so much more complex than the problem
I believe the DDD is great for Cabin-rental systems and Access card systems, but the SOA-solution? Well prove that you can handle a strategy of the common version of your data. I personally like to be threated as the same identity across the functions of the companys I interact with...
...this is a reason for working on MDM (Master data management).
just my 2 cent
have a good one
/G
Friday, March 18, 2011
Subscribe to:
Posts (Atom)
