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 

This image shows microservices business logic using a transaction script pattern. At the top of the image there is a section called “order service.” This section includes “create service,” “revise order,” and “cancel order.” Arrow lead from this section to sections labled “order DAO” and “order.” “Order DAO is included in a larger grouping with “order service.” This grouping indicates that both are classes with behavior. “Order DAO” includes “save (order),” and “Find Order by ID.” “Order Service” also points to “order” which falls under “classes with state.” “Order” includes “order ID” and “order line items.”

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 

This illustration shows microservices business logic in domain-driven design. The image is divided into two sections. On the left, under the label “some classes have only behavior” you see the sections “Order Service” which includes “create service,” “revise order,” and “cancel order.” Below this section is “Order Repository” which includes “find order by ID.” An arrow connects the two. The right side is labeled “Some Classes Have Only State.” The first section on this side is called “Delivery Information” and includes “delivery time” and “delivery address.” An arrows points down to the next sections called “Order.” This section includes “,” “Order ID,” “Order Line Items,” “Revise,” “Cancel”, “Static,” and “Create”. An arrow connects this section to “Order Service” on the left. At the bottom, the image reads Many classes have state and behavior.”

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. 

This image shows the flow of microservices business logic from order service (on the left) which includes steps 1 (Create Order) and 7. (Approve Order). In the middle is the message broker which includes order events, consumer events, ticket events, and credit card events. Things then flow into three categories on the right. These categories are customer service, which includes step 2, verifying customer details, kitchen service which includes steps 3 (create ticket) and 6 (approve ticket), and accounting service which includes steps 4 (create pending authorization) and 6. Authorize Card.


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.




Schedule a Free Consultation

Quickly ramp-up teams and accelerate the delivery of your new software product.