What Low Coupling and High Cohesion means in System development.

• Low Coupling and High cohesion.

We've all heard of this two terms in various settings. Today, I am exploring what they actually mean and why it is important to have one over the other in different circumstances. It is funny too, because most people only think of this once they are done with the project.

• Coupling.

Coupling is the interdependence between Software Modules or components. In layman's language, this means if the system is highly coupled, change in one module leads to changes across the whole system. That is like you hit one nail on the wall and the entire house collapses.

• Cohesion.

This is the degree to which the elements within a module or a component are related to one another. In layman's language, this means if the module has a high cohesion, then the elements are closely related and work together to perform well defined task. This is like how a typical football team works, every player has their fellow player's back and they support each other.

• So what is really needed in a System?

Ideally, a performant system should have Low coupling and high cohesion.

• Low Coupling- This results in better flexibility and easier maintenance because one doesn't have to know about every relation in the system while making a change.

• High cohesion- This makes the code more readable and easier to change because everything that needs to be known is there.

Steps to achieve low coupling and high cohesion.

1. The application should be thought of as Bounded contexts. This means that some crucial planning and actions are needed. For instance,

• Divide and conquer- Each module should do a fixed thing.

  • The functionalities should be kept separated from each other.(Think of Vertical slice Architecture).

  • Single ownership of data should be the most preferred and implemented as much as possible. Another alternative to this is having clear cut interfaces.

Understanding this concepts is crucial. The boundaries might not be well understood under the technical levels, however, real benefits will show up when these boundaries are understood on levels of business processes and the underlying domain.

That is it for now and thank you for stopping by.

See you in the next one.