Strategic Modeling
Context Mapping
Last updated
SC - Software Architecture
Context Mapping
Last updated
In Strategic Modeling, we learn to get a bigger Domain, understand it knowledge areas (which are its sub-domains) and find what is the best way to physically divide this into different code bases (Identify and define boundaries between the Bounded Contexts).
When modeling we must have a general vision on how things fit on each other.
Because eventually different Bounded Contexts will:
Complement each other,
Talk to each other,
One serve the other.
So we must create a more strategic modelling by mapping our contexts.
You can adopt DDD Strategic Modeling without adopting the Tactical Modeling.
Ex.: You can break your monolith application into diferent sub-domains (which now would kind of be like a Microservice architecture), and use a Transaction Script model which don't use any Domain Object types from Tactical Modeling.
As you better understand the business Domain, you end up dividing it in Subdomains and start recognizing the importance levels in each of them.
The definition of the Domain will result in the Analysis and modeling of it.
And the Domain modeling will result in understanding of the Subdomains problems that will usually result in Bounded Contexts.
The Domain is directly tied to the what the business mainly does. (General vision of it)
It is the problem, in business terms, that needs to be resolved independently of used technology.
It is the heart of the software.
(It is not always easy to extract the knowledge related to the domain)
This Domain is not the same as project's Domain.
Are parts of the software that together can generate and aggregate value to the business.
(More detailed and specific vision of the Domain)
Identify Subdomains is the possibility of dividing your codebase. (Not a rule)
The most important one, and the one that brings value to the company.
Where you put most and best effort on.
Ex.: Checkout subdomains of an Ecommerce.
Complements the Core domains/subdomains. Without these, it may be harder to succeed.
But you won't put too much effort on these.
Ex.: Stock subdomains of an Ecommerce.
Subdomains that can be delegated to other companies or even be third party applications.
Ex.: Login/Auth subdomains of an Ecommerce.
A Bounded Context is an explicit boundary within which a domain model exists. (Meaning a physical project)
It is the implementation of a Subdomain. Bounded Contexts are the division of codebase between different subdomains. (Meaning similar Subdomains can be in the same Bounded Context)
Inside the boundary all terms and phrases of the Ubiquitous Language have specific meaning, and the model reflects the Language with exactness.
The segreggation of Subdomains in Bouded Contexts are highly dependant on the nessary coupling between these Subdomains and the complexity to develop and integrate these projects separated.
Ex.: Bellow in the E-Commerce Bounded Context, you have 5 Subdomains that are highly dependant on each other. So segregating them on different projects would greatly impact performance, since they would have to communicate with each other all the time.
They determine what area of the business we are working on, what type of problem we are dealing with.
When the same word have different meanings, probably they are in different contexts.
But different words with the same meaning, also indicates that they are in different contexts.
When different contexts talks to each other, by Entities or Elements.
The Client is the same guy, but they are in different contexts.
They still should be separated, so that a Client class is not bloated with information to be used by different contexts.
(Ex.: Creating separated Client entities for each Bounded Context, even in a monolithic envirnoment)
Is how Bounded Contexts interact and integrate with each other.
Integration Patterns define the type of relationship between each Bounded Context in a Context Map.
When two or more Teams work synchronously in a deliver that involves two or more Bounded Contexts.
Ex.: Two different Teams develop different Bounded Contexts in a coordinated way. And they communicate to establish how these Bounded Context will integrate.
When you share code between Bounded Contexts.
It is relatively normal to share part of the code between several Bounded Contexts, specially for unrelated purposes (like infrastructure).
More technically, the code can be shared by a direct relationship in a monorepo or some type of versioned library published internally.
A managing dependency process is essential for reduced productivety impacts.
Ex.: Breaking changes in this shared library.
Ex.: Part of two Bounded Context projects are equal, so you segregate that to a separate project.
There is a relationship of supply where both the Customer and Supplier can determine how the contract (interface) should be between them.
Might be interesting to always have tests that garantee the integration health.
There is potentialy no partnership between teams, meaning they don't talk to each other.
So the Customer has to conform to how the Supplier provides his interface.
Ex.: When using an external third-party API, you probably won't be able to ask them to change their API for your needs.
A Bounded Context may make available a set of services using a default protocol with abundant documentation.
Ex.: An API that provide interface with different Versions (v1, v2).
Usually Conformist relationships demand a translation to your Domain. (So that you are not coupled to outside/third-party interfaces)
This is done by adapters (that translates interfaces), allowing your to use different or even change providers.
