Integration Strength

Any two or more coupled components share knowledge. The extent of the shared knowledge directly affects how changes propagate across the system. The more knowledge is shared, the higher the probability that a shared unit will change and trigger cascading changes across the coupled components.

To effectively manage cascading changes, we need to evaluate the extent of the shared knowledge. But how do you measure knowledge? In what units can it be quantified? There are no clear answers to these questions. However, we can approach the problem differently.

Types of Knowledge

Instead of attempting to “measure” knowledge, it’s more practical to categorize different types of knowledge. Each type involves significantly different amounts of shared knowledge. This is the foundation of the Integration Strength model.

Integration Strength identifies four fundamental types of knowledge that can be shared across component boundaries at all levels of abstraction: intrusive, functional, model, and contract coupling.

Intrusive Coupling

Intrusive coupling occurs when private interfaces are used for integration. Instead of relying on proper integration interfaces, other means—such as private objects, internal databases, or other implementation details.

This reliance on implementation details maximizes the risk that any change in the implementation will break the integration and cause cascading changes. The risk is further exacerbated when the authors of the “intruded” component are unaware of the integration at all.

With intrusive coupling, we must assume that all knowledge about a component’s implementation is shared. This makes intrusive coupling both fragile and implicit.

Functional Coupling

Functional coupling shifts the focus from how a component is implemented (intrusive coupling) to what it implements: its functional requirements.

Functional coupling occurs when multiple components share knowledge of their functional requirements. For example, two components implementing closely related functionalities will need to change together whenever the business requirements evolve.

An extreme case of functional coupling is duplicated knowledge. Consider the same business rule being implemented in both the frontend and backend. If a specification change is not reflected in both implementations simultaneously, the system will enter an inconsistent state.

Like intrusive coupling, functional coupling can also be implicit. In the example above, the duplicated business logic might exist in components that are not explicitly coupled, yet they still need to change together.

Model Coupling

Crafting effective models is a crucial aspect of software engineering. Since we cannot encode all knowledge related to a system’s business domain, we craft models to capture only the knowledge relevant to the system’s goals.

The domain-driven design methodology emphasizes the importance of working with multiple models. Instead of building one massive model for all use cases, it encourages specialized models tailored to specific problems.

Model coupling occurs when components share knowledge of a model. If the model changes–for example, due to new insights into the business domain–all coupled components must change accordingly.

Contract Coupling

The lowest level of shared knowledge occurs with contract coupling. The goal of an integration contract is to encapsulate all knowledge about implementation details, functional requirements, and business models, thus making integration contract explicit and stable.

Various design patterns introduce integration contracts, including: Façade, Open-host service / Published language (DDD), Anti-corruption layer (DDD), Data transfer objects (DTOs), and others.

As the above figure illustrates, the levels of Integration Strength reflect not only the amount of shared knowledge but also how implicit or explicit that knowledge is. Contract coupling is the most explicit integration method, while intrusive coupling is the most fragile and implicit.

Degrees of Integration Strength