Data Modelling: The right steps
There is a new client on the block and your boss is very happy with the profit perspectives. He invites every developer for this cool new product meeting and everyone starts to express their opinions about the project. You know that in the next few weeks you’ll have a new data model ready, I mean, this is the main expectation for these meetings.
The meeting starts with a list of requirements made by the client and it all goes nice and softly until someone shouts: “I think we are ready to draw the data model”. Now all developers are crazy, blasting entities and relationships on the blackboard and deciding which columns should each of those entities have as if entities could have columns…
If that is the reality of your data modelling meetings, then this article is for you.
Ubiquitous Language
Domain-driven design is a set of tools and techniques to model, implement and manage a knowledge domain. The first book, “Domain-Driven Design: Tackling Complexity in the Heart of Software (2004)” [1], was written by Eric Evans exactly 36 years after the term software engineering was firstly coined by NATO due to the “software crisis”. This means that it was created after more than three decades of knowledge gathering on the topic.
The first pages of the book express the need to design an ubiquitous language. There is no chance that a team of people working on a project will be able to develop good software without a ubiquitous definition of the domain-specific words, so it is good advice to focus on developing a common language to be used by the stakeholders before the beginning of the modelling process (that includes your clients). Once you do that, you are ready for the next step.
Conceptual Model
After having a strong ubiquitous language you will notice that most of the words represent an entity in your domain. Now it is time to start defining the relationships between these entities. Forget about tables, columns, attributes, cardinalities! All you want to do is understand how each entity relates to others.
Think of a mind map… With the ubiquitous language, you make your team understand what you are talking about and with the conceptual model you make your team understand the relationships, and if relationships they had in mind make any sense.
Bounded Contexts
You are ready for the most important step: Planning software that is ready to grow. No kidding! Pay close attention to this.
Now that you understand all the possible relationships between entities, you start to have a grasp on how you can group entities that relate to each other. Each cluster of these is called a bounded context. They allow you to understand your domain as parts and also to build software as “little” blocks.
What is the advantage of building software as little parts? Well… There are many benefits such as maintainability. Having small little pieces of software is much better than having a huge monolithic system. Another great advantage is the fact that we are part of a distributed computing revolution and bounded contexts are great candidates to become micro-services if your software grows a lot.
There is one great advantage that helps not only developers but the whole business. When you understand your bounded contexts, you are able to not only reduce maintainability costs but also to map how each context relate to another. The domain-driven design book aids developers and organizations by presenting strategies to solve the relationships between contexts. Some of them are:
- Shared Kernel
- Customer / Supplier
- Published Language
- Open Host Service
- Anti-corruption Layer
- Conformist
- Separate Ways
I’ll talk about those in a future article. Remember that domain driven design is a tool for both developers and managers.
Finally…
Now that you understand your problem, its contexts and the relationships between entities and contexts, you are finally ready to model the attributes and make small adjustments to refine your data model. This step is called “Logical Data Model” and is exactly what enterprises tend to jump to when they have to model a new product. Jumping to that step is one of the greatest causes of requirements’ misunderstanding and bad quality implementations.
There are many more tools to help in the domain modelling process such as event storming, subdomain modelling and aggregates. The objective of this article is to help people understand that before writing relationships and attributes, one must first understand and “standardize” the knowledge of the domain.
I have seen many enterprises that fail to model domains correctly and consequently to deliver what the client really wanted. I really hope this can be of great support!
References
[0] Breaking complexity using domain-driven design - https://www.mitrais.com/news-updates/breaking-complexity-using-domain-driven-design/
[1] "Domain Driven Design: Tackling Complexity in the Heart of Software" — Eric Evans
[2] Conceptual Model — http://www.sqlsuperfast.com/post/2011/02/20/Conceptual-Data-Model.aspx
[3] Bounded Context — https://martinfowler.com/bliki/BoundedContext.html
[4] Logical Model — https://sparxsystems.com/enterprise_architect_user_guide/12.1/images/logical_data_model_uml.png.png
