Practical Process Automation

Chapter 7. Autonomy, Boundaries, and Isolation

Modern systems are composed of many smaller components, like microservices. Microservices architectures value autonomy and isolation of the services. Every service is focused and follows the Unix philosophy: “Do One Thing and Do It Well.” This raises important questions on how to set the boundaries of a service. What functionality goes into one service or another, and how many services do you design? How do you achieve decoupling between these services?

These questions, or more so the answers to them, influence process automation, which is why it is important to cover these topics in this book. This chapter:

• Introduces domain-driven design and its ideas around coupling as important basics

• Describes how business processes can help you in designing boundaries

• Examines how boundaries affect your processes

• Discusses how workflow engines can run decentralized to respect boundaries

Strong Cohesion and Low Coupling

Let’s start with some basics around cohesion and coupling, which are opposite forces and need to be balanced carefully. You should aim for what is known as Constantine’s law: “A structure is stable if cohesion is high, and coupling is low.”

Cohesion has to do with how code is organized and how strongly the code in each component is related. As Sam Newman puts it in his book Monolith to Microservices (O’Reilly), “the code that changes together, stays together.” The idea is that one desired change in business functionality ...