Architecture tenets of High Cohesion and Loose Coupling

Architecture tenets of High Cohesion and Loose Coupling – Both of these tenets are related to one construct i.e. that of a “Contract”.

The term contract in information technology involves the definition of high level interfaces in the form of a coarse-grained set of operations that have well known inputs, output, clear exceptions or faults. The contract hides all of the details of implementation and allows these hidden implementation details to behave as one cohesive unit - in that it provides support for "high cohesion". By extension, in separating the client or consumer or caller of the contract from the implementation details it provides support for “loose coupling”.

This concept of contract works at any of the following levels:
1. sub-system interface (for example, a persistence sub-system)
2. component interface (for example, a remote monitor)
3. layers of architecture (for example, business layer vs. presentation layer)
4. infrastructure service (for example, a messaging service)
5. SOA style business service (an customer account self-service)

Furthermore, the concept works whether the implementation is a local call or a remote component call long as the "contract" is honored. Experienced architects also insist on unidirectional contract-based communication even between the layers of the architecture - with communication only being allowed to the very next layer down. The concept is that the more volatile layers interact with the more stable layers’ contract without skipping levels. This level of indirection adds as a check for the entire system as the volatility of top level layers and the communications from the volatile layers’ are limited to the very adjacent layer alone without affecting multiple aspects of the system when these layers change.

This concept is the key driver of the Model View Controller or MVC pattern wherein the presentation layer is allowed to talk to the interface or contract of the controller layer or the façade layer alone but not to the interface in the business logic layer or the data logic layer. Also, the façade layer or the controller layer is not allowed to communicate to the client or the presentation layer. The contract dictates that it is the client or the presentation layer that is responsible for initiating the communication.

Advantages of adhering to the Contract:
A) Implementation details can change without negatively affecting the consumer or the client. Loose coupling facilitated by the contract protects the client or consumer. Also, since the behavior is highly cohesive (all hidden behind the contract in one well-knit codebase) any alterations to business rules or behavioral logic is embedded in this codebase, thus insuring the completeness of apply the rule/ logic change. Without this it is very possible that part of the logic is embedded in consumer codebase and part of it may also be placed in the communication or the mediation layer (leading to the anti-pattern low cohesion and high coupling).
B) System integration testing and performance optimizations are easier when there is a known finite set of operations, inputs and outputs that will be allowed by the contract.
C) Understanding the interactions and invocations for the consumer becomes easier due to the known and pre-configured set of operations that are published on the contract. This helps to make the system or application more deterministic.
D) As long as the contract is not broken in making behavioral enhancements new consumers can be entertained without having to create newer versions of the codebase. Of course, this can also mean addition of newer audit and tracking capabilities in compliance with internal or regulatory policies without affecting or "informing" the consumer.
E) Since the consumer is not interacting with multiple internal points of the codebase, the system interactions and resource utilizations per consumer/ client call are more quantifiable and predictable. This makes it easy to scale the system for availability. This contract or interface then becomes the single point of entry for all interactions and is thus the only point that needs to be monitored to assess system resource utilizations. In addition, provisioning of system resources becomes more scientific as all calls of a certain operation take a known amount of time and resources given that the inputs are also quantifiable.

As can be seen, a simple construct such as “Design by Contract” when taken seriously and to its logical conclusion renders a great deal of architectural stability, robustness and extensibility.

As always your comments are welcome.
surekha -