Conformist

The conformist relationship between bounded contexts refers to a relationship in which one bounded context follows the same ubiquitous language and the same concepts used by another bounded context. In other words, the conformist bounded context adopts the model, language, and behavior of another bounded context.

This relationship is established when one bounded context is the clear owner of a particular domain concept or model, and another bounded context needs to interact with it or use its services. The conformist bounded context needs to conform to the terms and concepts of the owner bounded context to ensure a smooth interaction between them.

The conformist relationship is one of the less common relationships between bounded contexts and is usually established only in very specific cases where two or more bounded contexts share very close domains, such as in the case of microservices that need to communicate with each other.

Implications

The conformist relationship between bounded contexts in DDD means that one bounded context conforms to the other bounded context’s model, and any changes to the conformist model should follow the model of the provider.

Pros

  • Reduced complexity: Because the conformist bounded context is modeled after the provider bounded context, there is no need to deal with different models, and the two contexts can work seamlessly together.
  • Easy integration: Since the conformist bounded context is modeled after the provider bounded context, it is easy to integrate the two contexts together.

Cons

  • Loss of autonomy: The conformist bounded context cannot evolve independently of the provider bounded context, and any changes to the provider bounded context’s model will need to be reflected in the conformist bounded context’s model.
  • Dependence on the provider bounded context: The conformist bounded context is highly dependent on the provider bounded context, and any changes to the provider bounded context can have a significant impact on the conformist bounded context.
  • Possible performance issues: The conformist bounded context may have to perform additional transformations or conversions to conform to the provider bounded context’s model, which can impact performance.

Overall, the conformist relationship can be useful in situations where the provider bounded context is highly stable and unlikely to change, and where the conformist bounded context requires a high degree of integration with the provider bounded context.

Example

Here’s an example of a conformist relationship between two bounded contexts in a hypothetical e-commerce application:

One bounded context is responsible for handling orders and payments, while another bounded context is responsible for managing inventory. In this scenario, the inventory bounded context would be the conformist and the orders and payments bounded context would be the customer.

The inventory bounded context would provide a standardized interface that the orders and payments bounded context could use to query inventory levels and update inventory counts. The orders and payments context would conform to this interface, ensuring that any updates it makes to inventory counts are done in the expected way.

For example, the orders and payments context might use the following API to reserve inventory when an order is placed:

<code>inventory.reserve(productId, quantity);

The inventory bounded context would define this API, and the orders and payments bounded context would conform to it. This allows the two contexts to work together seamlessly, even though they are separate and independent.

When does it work?

The conformist relationship between bounded contexts works effectively in the following scenarios:

  1. When there is a clear and dominant context: The conformist bounded context should be less complex and less critical than the dominant bounded context.
  2. When the conformist context can tolerate changes: The conformist context should be designed to adapt to the changes made by the dominant context.
  3. When there are clear boundaries: The two contexts should have well-defined and distinct boundaries.
  4. When there is a stable and well-established relationship between the two contexts: Both contexts should have a good understanding of each other’s responsibilities and roles.
  5. When the conformist context can provide value to the dominant context: The conformist context should be able to offer something of value to the dominant context.

When does it not work?

The conformist relationship between bounded contexts may not work in the following situations:

  1. When the conformist bounded context becomes too complex, making it difficult to maintain a clear separation of concerns.
  2. When there is a need for frequent changes in the conformist bounded context, but it is dependent on other bounded contexts that do not require the changes.
  3. When the conformist bounded context is too tightly coupled to other bounded contexts, which can result in unintended consequences if changes are made.
  4. When the conformist bounded context is too loosely coupled to other bounded contexts, which can result in a lack of coordination and coherence across the system.

In general, the conformist relationship works best when the dependencies between bounded contexts are relatively simple and stable over time, and when there is a clear understanding and agreement between the teams responsible for each bounded context.