Also called strategic modeling, it is a pillar of the DDD whose main objective is to define the Bounded contexts, the Ubiquitous Language and the Context Maps together with the entire project team, which are the domain experts and the technical team.
To clearly understand what the strategic project is, you need to master each of these concepts I have spoken about.
Bounded context
Bounded context is one of the most important concepts of DDD, we can say that is a conceptual limit where a domain model is applicable.
As you try to model a large domain, you will have great difficulties, because different groups of people will use subtly different terms and sentences. That means that any use of that vocabulary outside of that limit will probably mean something different.
We can say then that a Bounded context is mainly a linguistic delimitation, as [Vaughn Vernon] speaks in his book.
It is important to understand that each Bounded context will have its own Ubiquitous Language.
As your model evolves, you will feel the need to create a relationship between the Bounded contexts, for this purpose we will use the Context Maps.
Ubiquitous Language
The Ubiquitous Language is modeled within a Bounded context, where the terms and concepts of the business domain are identified, where there should be no ambiguity. In order for you to develop an efficient Ubiquitous Language you need to understand the business.
One of the great advantages of the Ubiquitous Language is to bring together the domain experts, the technical team, and the others involved in the project. Ubiquitous Language should never be a set of terms and technical jargons imposed by domain experts, on the contrary, Ubiquitous Language is developed in agreement of the whole team. The Ubiquitous Language must be spoken at all times between the team members and expressed in the software model.
Context Maps
Context Maps help in understanding the whole project, being able to show the relationships between the different Bounded Contexts.
It is extremely important to understand the relationship between Bounded Contexts so that you can build a domain model correctly.
There are several ways to relate Bounded Contexts:
Shared Kernel
A shared context between two or more teams, which reduces duplication of code, however, any changes must be combined and notified between teams.
Customer / Supplier
It is a relationship between client (downstream) and server (upstream), where the teams are in continuous integration.
Conformist
It is the scenario that involves the upstream and downstream teams, but in this model the upstream team has no motivation to meet the needs of the downstream team.
Partner
It is the scenario where teams are dependent and need to have a cooperative relationship so that they can meet the development needs of both systems.
Anti Corruption Layer
It is the scenario where the client (downstream) creates an intermediate layer that communicates with the upstream context, to meet its own domain model.
There are also other integration models such as Open-host Service, Published Language, Separate Ways and Big Ball of mud (never do that).
In future articles, my intention is to further detail this subject and make practical examples.
See you soon!
