Your Guide to Microservices Business Logic
Need a partner with proven experience working with microservices?
Why do we need to design code around microservices business logic?
Think of it this way. Before building a skyscraper, an architect needs to create a blueprint. This blueprint communicates the plan with the builders, property owner, and other stakeholders. This allows everyone to weigh in with feedback and ensure the design meets customer needs.
This process is no different in the technology world. Experienced developers should always design their code before implementing it. This ensures that as the code evolves, it supports business requirements. This process also ensures the code is maintainable, extendable, easy to understand, and adaptable.
Looking for more tips on how to create quality code? Check out our 2 part blog series – Smart Strategies to Deliver Quality Code.
Having the design in place will help developers of all programming levels to:
- Write code in the correct place (application component, package, module, class, function, script, etc…) within the application source code.
- Troubleshoot and find the code needed to understand and update the application features quickly from existing code (legacy or in-progress implementing code)
- Maintain consistency of the whole application and not break the design of the software architecture.
How do you incorporate business logic into a microservices architecture?
There are two approaches for organizing business logic in a microservices architecture: transaction script or domain-driven design (DDD)
Deciding which approach to take depends on the application’s business requirements.
Read more! Going from Monolith to Microservices: How to Get Started.
Transaction Script Pattern
Transaction Script Pattern is one of the simplest domain logic patterns. Choose this approach when business requirements are simple to understand and implement.
In this pattern, the script will load data from the database. It will then perform a simple business logic, and reply to a request from the presentation.
This pattern works well with functional programming such as javascript (and node.js runtime). It can be implemented with OOP-languages such java.
While easy to work with, this pattern is not effective for complicated business logic. For example, say a client ask for new features with more requirements. Things can get messy
You will need to write many transaction scripts, creating duplicate and complicated code. This makes it hard to maintain the consistency of the entire application.
To prevent this, write code carefully. You should refactor out common code and structure modules to manage the platform.
Domain-Driven Design
Domain-Driven Design better handles complex business logic. It is the standard choice for enterprise applications.
This design is easy to understand and maintain. Classes such as order, account, banking transaction, and overdraft policy mirror their real-world counterparts.
When you deduce classes from business requirements, you understand the business logic.
Object-oriented design is easier to extend because it can use well-known design patterns. For example, it can use the Template method and Abstract factory.
Designing a Domain Model Using the Domain-Driven Design
Domain-driven design requires separating the business logic into different classes.
But, how do you know which aspects of the business logic belong to which parts of the classes?
Microservices architectures become complex when you spread business logic across multiple services. To tackle this complexity, we have to account for 2 important requirements:
- Eliminate object references that crossover service boundaries.
- Solution: Referenced by identity through aggregates, aggregate forms an explicit boundary.
- Focus on DDD concepts: Aggregate
- Design business logic to meet the constraints of distributed transaction (ACD, Atomicity, Consistency, Durability) management in microservices architecture AND it works as expectation of business requirement as a Business Unit of Work through customer point of view.
- Solution: Using domain event to notify state change of domain models so that coordinated services can react correctly such as synchronizing view replica in CQRS pattern, or doing the corresponding business logic of its responsibility
- Focus on DDD concepts: Domain event, bounded context
Example of Microservices Business Logic Using Domain-Driven Design
To explore this further, let’s walk through a common business requirement: creating an order for a restaurant. Let’s say a customer places an order. The restaurant accepts the order and the credit card is authorized and handled by accounting.
To complete this requirement, we need to split the process into its business logic. We then sort business rules into the corresponding microservice. Take a look at the image below to see how this works for microservices.
Summary: Microservices Business Logic
When building software, it is important to design using business logic. In a microservices application, you can choose different approaches for each individual microservice. This gives you the freedom to customize based on specific business requirements.
Microservices architectures can be complicated! Make sure you know 7 major mistakes to avoid when moving to Microservices.
Transitioning to a microservices architecture? KMS can help you weave business logic into your platform.
