Product manager, you don’t understand high cohesion and low coupling?


When discussing system design with architects, the voices of “high cohesion” and “low coupling” can always be heard everywhere, as if this is a wall between architects and product managers, a gap between primary and advanced. But if you understand their principles, it will not be so magical. You must know that these two words are not dedicated to research and development. As product managers, our understanding of these two words can be even broader than that of architects.

A Living story

The story begins like this:

What are high cohesion and low coupling?

To put the story aside, let’s first understand what cohesion and coupling are.

3. How to achieve high cohesion and low coupling

From the definition, we should be clear that high cohesion and low coupling actually mean two things, one internally (high cohesion) and one externally (low coupling). From the perspective of products, high cohesion and low coupling should not be limited to the level of system design, which will be narrow. The correct interpretation should be based on the two levels of business and system.

1. Business level

Whether the division of responsibilities of business departments, the planning and design of processes, or the management of operation sites, all need to follow the principle of high cohesion and low coupling. We should try to centralize the management of the same feature, processes and operations as much as possible, while the responsibilities and boundaries between different features, processes and operations are clear, the communication and cooperation are smooth and do not affect each other, which is specifically reflected in:

2. System level

When doing system design, it is necessary to ensure that the same system and feature modules are as cohesive as possible, and the systems and feature modules are decoupled as much as possible, which is reflected in the following:

  • The features of system and module are single and the boundary is clear. When planning the system, each system and each feature module under each system should have clear responsibilities, and there is only one core responsibility, and there is a clear boundary with other modules to avoid ambiguity. For example, the inventory module is responsible for handling all inventory related matters, and the inbound module is responsible for handling the inbound process. The boundary between the two is the operation of inventory during inbounding, which is triggered by the warehousing module and executed by the inventory module.
  • Unified data and logic. There should be only one responsible party for each data and logic operation. When other modules need to operate this data, they should be authorized by this module and communicated through interface services, so as to maximize the integrity and security of data and features. For example, both inbound and outbound operations need to operate inventory, but the logic of inventory is handled by the inventory module. Inbound and outbound operations of inventory need to interact through the interface provided by the inventory module, and do not directly hand over the processing of inventory to inbound and outbound.
  • Interact with as few systems as possible to reduce complexity between systems. Refer to Demeter’s Law in Software Design Principles: Talk only to your immediate friends and not to strangers, try to avoid interactions between multiple systems, and form Cartesian product and network structure. For example, there are 3 ERPs on the top, and they all need to interact with the 3 WMS systems below. At this time, you should consider using an intermediate system to undertake 3 ERPs for the top and 3 WMS systems for the bottom. Do not let each The ERP forms a Cartesian product with each WMS separately.
  • The system design comes from the business. Before doing the cohesion and coupling of the system, first sort it out from the business level to make the business do a good job of high cohesion and low coupling. Many times, the problem is not the system, but the business side does not do a good job of cohesion and decoupling.
  • In the early stage of business development, when the process and system are relatively simple and the future is not yet clear, quick trial and error is required. You don’t need to think too much about cohesion and coupling (just take it into account), first support the business in the lowest cost way, and wait for the business to become clear. It is not too late to continue to adjust in the future. Don’t over-design. It is a real waste to undertake the business of 1,000 orders with a scale structure of 100,000 orders.
  • If the business is relatively stable and unchanged for a long time, proper coupling will be more reasonable, such as the basic attributes of commodities, key information of orders, address database information, etc. It is not necessary to do interface interaction every time for low coupling, which is a waste of performance.
  • When the business volume and team size are small, it is suitable for the sharing mode. In a set of system, it is most reasonable to consider high cohesion and low coupling according to modules; When the business scale is large, it is suitable for self occupied mode and divided into multiple systems. The internal cohesion of each system is high and the low coupling between systems is more reasonable.

4. Bob’s Story Case

Finally, we share a Bob’s story to strengthen the understanding of high cohesion and low coupling.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store