Microservice architecture has become a widely adopted approach for building scalable and maintainable systems. However, one of the most complex decisions when implementing this architecture is defining the scope of each microservice. Should you split functionalities into separate services or keep them together? The answer lies in balancing what I call _integrators_ and _disintegrators_—factors that either encourage combining functionalities or suggest splitting them into distinct services.

In this blog post, I’ll break down how these integrators and disintegrators guide the microservice design process and help define the right boundaries.

## **The Role of Integrators and Disintegrators**

In this context:

- **Integrators**: Factors that suggest combining functionalities within a single service.

- **Disintegrators**: Factors that push you to separate functionalities into distinct services.

Balancing these factors ensures your microservices are scalable, maintainable, and resilient.

## **Disintegrators: When to Split Functionalities**

1. **Code Volatility** If certain functionalities change frequently and independently from others, it’s better to split them. This allows you to update one service without affecting others, reducing the risk of deploying changes.

2. **Access Control** Services with different access control requirements should be separated. Trying to enforce varying levels of security and permissions within a single service can lead to complex and error-prone configurations.

3. **Cohesion** High cohesion is critical for service maintainability. If different functionalities within a service are not tightly related in purpose, splitting them reduces unnecessary complexity and improves service focus.

4. **Fault Tolerance** If a failure in one part of a system should not cause the entire service to fail, separating functionalities ensures better fault isolation. This approach improves overall resilience by containing failures within specific services.

5. **Scalability** Different components often have unique scaling requirements. Splitting services based on how they scale individually allows for more efficient resource utilization and better performance.

## **Integrators: When to Combine Functionalities**

1. **Data Dependencies** When multiple functionalities rely on the same data model or require tight data consistency, combining them within a single service avoids complex distributed transactions and synchronization issues. Domain driven design helps to determie right bounded context of your domain, which is a huge factor in the microservice scope definition.

2. **Workflow** Complex workflows that involve multiple tightly coupled steps are better managed within the same service. Splitting them across multiple services could lead to unnecessary inter-service communication and increased latency.

3. **Database Transactions** Distributed transactions across services are often a red flag in microservice design. If certain operations require atomic transactions, it’s generally more efficient to keep them within a single service, simplifying both design and implementation.

## **Conclusion**

Designing microservices is a balancing act. While disintegrators encourage splitting functionalities for better autonomy and flexibility, integrators highlight cases where combining functionalities can simplify data consistency, workflows, and transactions.

There are no one-size-fits-all rules for defining microservice scope, but by analyzing the integrators and disintegrators relevant to your domain, you can design services that are well-scoped and aligned with both business needs and technical goals.

Ultimately, the key lies in understanding your domain deeply and making pragmatic decisions about service boundaries. With the right balance, you can create a microservice architecture that is both flexible and sustainable.

Defining Microservice Scope - Integrators and Disintegrators

Domain driven design (DDD) is a methodology for designing software with a focus on the domain. DDD is one of the main practices used in the microservices development. I'll cover 3 main concepts of the DDD:

- Ubiquitous Language - use the same language/terms in the code and in the business. This allows programmers to talk to the business people without misinterpretation.

- Aggregate - Related objects, that form a consistency boundary and are treated as a single unit. For example in the "Customer" domain, "Address" is an aggregate.

> An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes. Each aggregate has a root and a boundary. The boundary defines what is inside the aggregate. The root is a single, specific ENTITY contained in the aggregate.

_Domain Driven Design, Eric Evans_

- Bounded Context - a logical and physical boundary around a coherent and consistent domain or subdomain

What if you already have a domain and want to slice it to migrate from the monolith to the microservices, for example? You can do this using these patterns:

- Volatility - split by the performance sensitive parts

- Data - split by usage or restrictions on the data

- Technology - split by a technology stack

- Organizational - align with the company organizational structure

_Microservices, 2nd edition by Sam Newman_