Strategic Modeling
Context Mapping
About
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 DDD (Domain Driven Design) (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.
Problems vs Solutions
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.
What is a Domain?
The Domain is directly tied to the what the business mainly does. (General vision of it)
(It is not always easy to extract the knowledge related to the domain)
This Domain is not the same as project's Domain.
What are Subdomains?
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)
Types of Domains/Subdomains
Core/Basic
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.
Support/Auxiliary
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.
Generic
Subdomains that can be delegated to other companies or even be third party applications.
Ex.: Login/Auth subdomains of an Ecommerce.
Bounded Contexts
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)
Subdomains and Bounded Contexts
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.
Contexts
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.
Transversal Elements
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)
Context Map
Is how Bounded Contexts interact and integrate with each other.
Integration Patterns
Integration Patterns define the type of relationship between each Bounded Context in a Context Map.
Example of using these Patterns
Partnership
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.
Shared Kernel
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).
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.
Customer-Supplier Development
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.
Conformist
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.
Open Host Service
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).
ACL (Anticorruption Layer)
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.
Published Language
Separated Ways
Big Ball of Mud
Last updated