The Benefits of Domain-Driven Data (DDD) Modelling

Data Modeling, Is it Dead?

This a fundamental question, and we have certainly noticed the following viewpoints about Data Modelling:

1. We don't see the value of Data Modeling
2. It is hard to convince the Organisation to invest in a Data Modelling Practice / Capability.
3. We don't need a Data Model for Agile Development
4. NoSQL databases don't require Data Models

Understanding these viewpoints is very helpful to my own learning. I loved a comment from an exceptional mentor: When you find yourself saying, "I don't KNOW why ABC behaves like DEF", then you know that you are the one who needs to learn and understand.

Pascal's webinar was another great opportunity to learn.

It is important to ensure that you go back to first principles:

1. Domain: Specific area of knowledge, influence, or activity of an application.
2. Subdomain: Space of the problem within a domain
3. Bounded Context: Represents a specific solution part of a (sub)domain where a particular model is defined and used consistently. A context requires a clear boundary, ubiquitous language (business glossary), isolation (API), and integration (canonical model).
4. Context Map: Manages the relationship between bounded contexts within the system. It also maps the interactions by visual representation.
5. DDD: Deal with large models by dividing them into bounded contexts and being explicit about their interrelationships. Acts as the conceptual foundation for Software design.

DDD divides a large system into domains and bound contexts within a domain. Each bounded context defines a unified model. The fundamental principle is that total unification of a domain model for a large system is not feasible or cost-effective. And this is where large data models like Enterprise Data Models have suffered.

The alignment between domains, bound contexts, and business capabilities is critical. Business Capability is a core function that a business needs to deliver a value proposition to a specific customer or stakeholder. It is part of the Business Value Chain. It is important to note that the Bounded Context should map to a single Business Capability. It is not the same as a capability; it encapsulates and supports a business capability within a domain. Hence, the term solution space.

So, what have I learnt:

1. Data modelling is not dead; it has been aligned and refined to a bounded context and a common language scope.
2. Business Alignment is still required and helpful for defining problem and solution spaces.
3. DDD focuses on software design, which does not mean it dictates the enterprise data warehouse's (EDW) design; it must also align.
4. The purpose of the EDW is to provide a comprehensive view of the business by integrating data and grouping according to Subject Areas. We still need to be careful to refine our EDW so that it is feasible and cost-effective

Other important Data Modelling viewpoints:

1. Data Modelling is a means to communicate what the end looks like. It is not the end!
2. Agile requires a balance. Data modelling, documentation, and planning are still required, but at the right level.
3. Code First is problematic when the developer's understanding is incorrect, and it may be better to restart and try to fix it.
4. Applying AI and Machine Learning to the bounded context is something to consider

Thanks to Pascal Desmarets for challenging our viewpoints and stimulating our desire to learn.

Comment on this article to receive the recording and learn more!

#damasa #datamanagement #datamodeling #domaindatadriven