# Strategic Modeling
## 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 [#bounded-contexts](#bounded-contexts "mention") *(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.
{% hint style="danger" %}
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.
{% endhint %}
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)*
{% hint style="info" %}
*It is the problem, in business terms, that needs to be resolved independently of used technology.*
It is the heart of the software.
{% endhint %}
*(It is not always easy to extract the knowledge related to the domain)*
{% hint style="danger" %}
This Domain is not the same as project's Domain.
{% endhint %}
## 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)*
{% hint style="warning" %}
Identify Subdomains is the possibility of dividing your codebase. *(Not a rule)*
{% endhint %}
### 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)*
{% hint style="info" %}
Inside the boundary all terms and phrases of the Ubiquitous Language have specific meaning, and the model reflects the Language with exactness.
{% endhint %}
### 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
{% embed url="" %}
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)*.
{% hint style="info" %}
More technically, the code can be shared by a direct relationship in a monorepo or some type of versioned library published internally.
{% endhint %}
{% hint style="danger" %}
A managing dependency process is essential for reduced productivety impacts.
*Ex.: Breaking changes in this shared library.*
{% endhint %}
*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.
{% hint style="warning" %}
Might be interesting to always have **tests** that garantee the integration health.
{% endhint %}
### 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
## What is a Domain?
The Domain is directly tied to the what the business **mainly** does. *(General vision of it)*
{% hint style="info" %}
*It is the problem, in business terms, that needs to be resolved independently of used technology.*
It is the heart of the software.
{% endhint %}
*(It is not always easy to extract the knowledge related to the domain)*
{% hint style="danger" %}
This Domain is not the same as project's Domain.
{% endhint %}
## 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)*
{% hint style="warning" %}
Identify Subdomains is the possibility of dividing your codebase. *(Not a rule)*
{% endhint %}
### Types of Domains/Subdomains
### 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
{% embed url="
#### Example of using these Patterns
*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)*.
{% hint style="info" %}
More technically, the code can be shared by a direct relationship in a monorepo or some type of versioned library published internally.
{% endhint %}
{% hint style="danger" %}
A managing dependency process is essential for reduced productivety impacts.
*Ex.: Breaking changes in this shared library.*
{% endhint %}
*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.
{% hint style="warning" %}
Might be interesting to always have **tests** that garantee the integration health.
{% endhint %}
### 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