A Decision Model for Selecting Patterns and Strategies to Decompose Applications into Microservices
Abstract: Microservices Architecture (MSA) style is a promising design approach to develop software applications consisting of multiple small and independently deployable services. Over the past few years, researchers and practitioners have proposed many MSA patterns and strategies covering various aspects of microservices design, such as application decomposition. However, selecting appropriate patterns and strategies can entail various challenges for practitioners. To this end, this study proposes a decision model for selecting patterns and strategies to decompose applications into microservices. We used peer-reviewed and grey literature to collect the patterns, strategies, and quality attributes for creating this decision model.
Whiteboard
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What is this paper about?
This paper is about helping software teams break big apps into smaller, easier-to-manage parts called microservices. It introduces a “decision model” — basically, a step-by-step guide — that shows which patterns and strategies to use when splitting an application into microservices, and what effects those choices have on the app’s quality (like speed, security, and reliability).
Think of a huge school project: instead of one person doing everything, you split the work into clear parts for different teammates. Microservices do the same for software.
What questions does it try to answer?
In simple terms, the paper asks:
- When you’re turning a big app into microservices, what are the different ways to split it up?
- Which ways work best for different situations (like team size or business needs)?
- What good and bad side effects do these choices have on important software qualities (such as performance and security)?
- How can we help developers choose wisely without reading dozens of separate articles?
How did the researchers study it?
The authors built their decision model by reading both:
- Peer‑reviewed research (academic papers),
- Grey literature (trusted blogs, company guides, and industry write-ups).
This “multivocal literature review” means they listened to many voices — both academics and practitioners — to collect:
- Common patterns and strategies for decomposing apps,
- Important quality attributes (QAs) like speed, scalability, security,
- How each pattern affects those qualities (good or bad).
They also used a diagramming method called BPMN to show decision flows:
- Inclusive gateway: you can choose multiple paths (like doing several tasks at once).
- Exclusive gateway: you choose just one path (like picking one option).
- Parallel gateway: you run multiple paths at the same time (like parallel work streams).
All of this was organized into a clear, visual decision guide.
What did they create and find?
The main result is a decision model focused on “application decomposition” — the step where you break a monolith (a single, big app) into microservices. The model helps you decide based on practical factors (like the size of your team) and the qualities you care about most (like speed vs. flexibility).
They collected and explained several well-known patterns and strategies. Each has trade-offs, meaning it helps in some ways but may hurt in others. Their model shows:
- When to use each pattern,
- Which qualities it improves,
- Which qualities it may weaken,
- Any constraints or special requirements,
- How patterns can complement each other.
Examples of patterns in plain words
Here are the key decomposition patterns and strategies the paper summarizes (explained simply):
- Decompose by subdomains: Split the app based on parts of the business domain (from Domain-Driven Design). Good for clear boundaries, flexibility, and reliability. Requires a solid understanding of the business.
- Decompose by business capabilities: Split the app by what the business does (like “Payments,” “Orders,” “Shipping”). Can improve performance and security, but may reduce flexibility because your design closely follows the business structure.
- Service per team: Each small team (around 5–9 people) owns one microservice completely (coding, testing, deploying). Improves availability, scalability, performance, and maintainability. If the project becomes very large and teams multiply, costs can rise.
- Decompose by transactions: Group services around business transactions (like “purchase” or “refund”). Helps with response time and data consistency but can increase coupling (tight connections) and execution cost.
- Scenario-based analysis: Write out real-world scenarios, then find microservices by looking at the “nouns” (things) and “verbs” (actions). It can improve scalability and performance but may lead to fuzzy boundaries if the scenarios aren’t precise.
- Graph-based approach: Analyze the existing code (of a legacy monolith) using clustering and visualization to find natural service boundaries. Boosts code reusability and understandability of the system’s structure.
- Data flow-driven approach: Use data flow diagrams (DFDs) based on business requirements, then cluster related processes and data stores into microservices. Increases availability and scalability but can reduce performance and reusability if the DFDs are complex.
Why these findings matter
- Different teams and apps have different needs. This model helps match the right approach to the situation.
- It makes trade-offs visible: for instance, focusing on security and performance may reduce flexibility, or optimizing for speed can increase complexity.
- It saves time: instead of searching across many sources, you get a single, organized guide with patterns, effects, and constraints.
Why is this important?
Microservices are popular because they let teams build parts of an app independently, deploy faster, and scale better. But splitting a big app into microservices is tricky — choose the wrong boundaries, and you can make things slower, more complex, or harder to secure.
This paper gives teams a practical, research-backed map for making those choices. In other words, it helps turn “breaking things up” into a smart plan instead of guesswork.
What’s next?
The authors plan to:
- Extend decision models to other microservice areas (like security, communication, and service discovery),
- Test and refine the models in real companies,
- Build a recommendation system that suggests patterns and strategies automatically.
If successful, these steps will make designing microservice systems faster, more reliable, and better suited to each team’s needs.
Collections
Sign up for free to add this paper to one or more collections.