Coupling and Cohesion
We don’t talk about this here directly, but it applies to much of the customization work we do. Here’s a quick video that explains it well. It’s less than 14 minutes for those weird people who listen at full speed.
Video:Coupling and Cohesion - Derek Comartin
Coupling
Briefly, processes can be tightly or loosely coupled. In a tightly coupled system, each process has to know a lot about the internals of the service being called. For example, when we call an Epicor REST end point for a business object, we might need to know about the RowMod property. This is tightly coupled. If I call an Epicor Function and pass it just data and the function calls the business object on our behalf, it hides those implementation details. This coupling is looser. If I use a local .DLL to interact with Kinetic, that is really highly coupled since I also have to match the version with the server. If I create my own REST API that interfaces with an Epicor Function, that coupling is looser.
In general, highly coupled systems are harder to test and more difficult to change as the requirements or environment changes.
Cohesion
On the other hand, we have cohesion. This is the measure of how well the elements of some module all work toward solving a single task. My favorite example of cohesion is with notifications. If I have a BPM or Function whose primary task is to validate a record, then all of the code should be related to checking that record. If it does, that code has high functional cohesion. Now, let’s say we want to be notified when the record is not valid. Because most of us grew up with AOL, the only possible way there is to notify someone is by email - sorry Gen Z and Gen Alpha. If we add code that directly calls the SMTP server to send an email notification, this code has low cohesion. Sending mail is NOT the primary task of the validation routine.
Instead, we can set a status on the record. A trigger then calls a service whose primary task is to notify when the status contains the value “FAILED.” This keeps the details of sending emails out of our validation code. It does even more than that. It promotes code reuse so there is only one notification service to maintain, and other triggers can use this service too. It also promotes the ability to notify users in a way they want to be notified: text, Slack/Teams, mobile app, Help Desk Ticket, Planner Task, or yes, even an email. (
)
As Derek mentions in the video, often these goals pull us in different directions. While highly coupled solutions work at first, they are difficult to test, maintain, and adapt. High cohesion solutions also work but can lead to systems with more moving pieces. It takes time and context to find the right balance.
BTW, Derek has many other great videos related to architecture and design, and I highly recommend them.