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.