Have you ever faced communication problems while working on a project? Two different teams at least are included in the process of creating an online store: developers who see the project from an agency side and those people who are engaged in it from a business owner’s side. In the latter case, it could be marketing directors, sales assistants, etc.
No wonder teams often don’t understand each other since they may name different things the same. But there is a set of practices that help us to overcome this issue. In this article, we are going to talk about Domain-Driven Design.
What is Domain-Driven Design?
Domain-Driven Design (DDD) is a set of techniques and recommendations that eases development and maintenance processes significantly. Besides that, it has to do with communication and design issues. DDD makes business processes easy-to-understand and more straightforward to implement.
Imagine a task to automate a vast logistics hub that accumulates orders and ships products. It would be an extremely sophisticated system! It could consist of dozens of product categories and storage precautions. Options to define how many items a delivery medium should be loaded with could be even more.
In this case, if teams don’t have a standard glossary, they will inevitably face big issues with automatization and integration. That’s why DDD offers a ubiquitous language as a remedy.
What Is Ubiquitous Language?
Ubiquitous language is a term that describes a common and accurate language that should be adopted by everybody who has to do with a particular project. This language is aimed at making a working process clear to technical specialists as well as to responsible persons from a business side.
So, what does it mean to build a ubiquitous language? First of all, you have to compile a glossary with all the terms you use on a project. Every person involved in the project has to have access to it, and all of them have to learn the terms and use them following their specified meanings — no matter in a code or during a discussion. The language is used in all cases regarding the project.
Take into account that the same word may mean different things to different people. For instance, “guest” in eCommerce means a prospective buyer that has already visited your store but hasn’t authorized yet, while “customer” describes a person that is already signed up. “Customer” is also an order element. But wait, there is more!
There are a lot of differences between “customers.” They could be either B2B or B2C customers and have a bunch of similar and contrasting characteristics. Online store owners may not know all of these details and designate the mentioned entities as just a “customer.”
Such misunderstandings can result in a situation where the platform works incorrectly and has security breaches.
Bounded Context and Domain Model
A ubiquitous language also helps to define a bounded context and describe a domain model.
Bounded context is a logical boundary where an entity has only one meaning. It is important to set such boundaries to avoid confusing terms and their definitions. As we mentioned above, “customer” in eCommerce means a signed up user and an order element simultaneously. In spite of the same name, these entities refer to contrasting domain models. They have to be implemented in totally different ways.
The domain model is a representation of real-life business processes in software. It consists of the data that is used in business and rules applied for the data operations.
Bounded context and domain models should be developed on a base of the ubiquitous language. That’s why compiling a glossary first is so crucial.
When you start building the ubiquitous language, make sure the team from the online store owner’s side joins the process. Everybody has to take part in developing it to share their vision on what words mean. Cooperation makes the code pure and easily maintainable.
The very first thing you have to do when you start a new project is to compile a universal dictionary to avoid misunderstandings. Having developed a glossary, you’ll be able to describe a domain model and its components as well as plan work and choose technologies to implement.
We hope this article was useful to you. If you still have questions, feel free to contact us via the form below.
We thank Alexander Shkurko for help in preparing and writing this article.