Component Principles

A Component is the smallest deployable unit of the system, This does not necessarily mean that they need to be deployed independently they can surely be a part of a bigger deployment.

1 Component Cohesion Principles

Principles to consider while deciding what modules to include in a specific component

1.1 The Reuse/Release Equivalence Principle

• The modules that are grouped together as a single component should be released together.
• Thus, the granule of release is the same as the granule of reuse which is the component.
• It is better to use release cycles. Each release should have a number.
• The dependent components can decide which release(differentiated by release number) they want to stay on.

1.2 The Common Closure Principle

• Modules that change for the same reason stay in the same component
• This SRP applied at the level of components.
• The contrapositive of the rule that is if the modules do not change for the same reason separate them into different components also should be followed

1.3 The Common Reuse Principle

• Modules that are not to be reused together should not lie in the same component.
• This is ISP applied at the level of components.
• The direct implication of this rule is to not make other components or classes depend on components that they do not need to. So make component divisions keeping in mind to keep modules that are used together in the same component and put the other somewhere else

2 Component Coupling Principles

Principles that govern the relationships between components

2.1 The Acyclic Dependencies Principle

• There should be no circular dependencies for components.
• Circular dependencies might create issues in the release cycles
• Imagine you worked on component A depending on component B
• But Component B also depends on Component B. The developer working on Component B also worked at the same time. Now in the next release both the component may break. This cycle would keep on going and would lead to long resolution meetings
• Common solution to this problem is to break the cycles.
• The dependency inversion principle(create an agreement that is implemented by both the components) can be used to reverse the direction of dependency in one direction

1.2 The Stable Dependencies Principle

• While deciding the direction of dependency the rule to depend in the direction of stability would be the way to go
• A common example is this Presentation Layer → Controllers → Business Logic
• If the dependency is the reverse of this use DIP to invert the dependency