Extending Model Driven Design beyond codes

Whoever is familiar with Eric Evans should also be familiar with the following diagram:
The diagram pretty much is an essence of a good design. Even though mostly referred when working on one application and how components should be created also has a potential to extend it to higher view for Enterprise solutions. Besides the importance of Entities itself, two interesting pieces of the diagram are "Services" and "Repositories". They are not just a set of APIs but are extended to Infrastructure as well.

• What about Services? How does a business create Services? How does it manage them? How can these services be orchestrated? And combined to produce a work flow? SOA combined with BPEL is what fills in the services gap.


• Now what about the Repository and Aggregation? Again its not just API but how would you manage Gigabytes and gigabytes of data in a fault tolerant and high performance way? And how to maintain integrity of your Entities with this data management system. Oracle Coherence is what offers a perfect solution to address the infrastructure behind Repository and aggregation.

Concept of Entities is when an Object has an unique identity, matches perfectly for what a Map is designed for. And Coherence is built for very large data set with a simple Map interface of NamedCache. The question is what to manage in this Map? Entities or Value objects? Entities do have IDs. Vis-a-vis value objects? Why not? Objects already have a behavioral identity in its' hashCode (). Isn't there a difference between an ID and Identifiable. Last part: Factories and layered architecture. Factories can very easily hide behind services and unique interfaces for each individual applications. I can't see any centralized concept for Factories.. Can you?