Is Domain-Driven Design a right fit for a product in Enterprise Architecture Domain?

Question

Our client has a requirement to re-design from scratch a product in an Enterprise Architecture Business Domain. The product has an ability to model business processes, information, technology, infrastructure, data etc. for the entire organization of the end user with the help of standard E.A. Framework methods & tools like BPM/N, TOGAF, ArchiMate, etc.

There are many abstract (meta) modelling concepts which enables the product to also integrate with multiple third-party systems e.g. ERP, CRM, Project Management, Financial Management & Service Delivery systems of the end-customers for data synchronization purpose.

The question - Is Domain-Driven Design a right fit for modeling the core domain of this kind of product?

Answer 1

I recommend reading the books "Domain-Driven Design" of Eric Evans and "Implementing Domain-Driven Design" of Vaughn Vernon. The first thing to realize is NOT to build the ONE big model that rules them all. DDD is about domains (one of which is the core domain) and subdomains. And it is about bounded contexts which could be connected in a variety of ways described in the books. So basically you will end up with a lot of autonomous subsystems with seemingly redundant data, that communicate with each other in an loosely coupled way and synchronize part of their data with loosely coupled communication. Much overarching constraints will be only eventually consistent and system, processes and users must tolerate this.

So in a landscape of the complexity you describe I think YES. DDD is a right fit for possibly several core domains of several systems. But feel free to use simpler methods in subsystems that are pure crud and data centric.

Answer 2

The Enterprise Architecture project will provide a layered model of your business... it will precise all the componentized parts of your domain : actors, departments, services, functions... If your goal is to align the solution on the domain (as I suppose), I think Domain Driven Development is a very good fit for what you are trying to achieve. Basically, EA can show you how your solution should look like. As DDD is all about "specialization", rather than "reuse" or "generalization", you should be careful on not depending on Legacy Services that could break your Bounded Contexts (in DDD, for instance, Business Rules implementations should remain in the BC they serve, and not being scattered in the whole solution across external dependencies...). EA is a wonderful tool to define Ubiquitous Language, Bounded Context boundaries. DDD is great at designing Services boundaries. EA will provide strategic tools that will help you designing the BCs. As DDD, SOA, EA share many common first-citizen principles, they will fit very well.

My contribution comes late, have you some experience to share with us ?