Microservices Design Principles and Best Practices to Keep Clean Architecture

Scalable and maintainable software is still something everyone wants. People fighting over microservices and monoliths are not a thing anymore. Everyone is stuck in either technical debt or monetization on the tough market. That’s why we need to talk about proper architecture before we develop anything. It’s a preventative measure ??

Every software architect (that can actually code) would say that both technical specifications and business principles matter. But focusing on business is something that allows clearer separation. Let’s take the “Clean Architecture” principle and apply it to microservices.?

Case when Microservices are a Necessity

You have a giant mature monolith and lots of devs. The more it grows, the longer it takes to deliver features. The typical problems would be slow releases, frequent rollbacks, feature toggling, etc. The choice to split into microservices is preferable here. But the main reason still should be the business one. The below picture shows you where is the point of considering microservices.

Usually, that’s about scaling in different industries that don’t fit together. Real estate and jobs would need different products or features, right? Of course approach to architecture is not the only thing that changes. Going from functional teams to cross-functional ones is one way to adjust.?

? Tip 1. Separation means Independence

Cross-functional teams are different from the department systems we are used to. Each micro-service should be deployable, and maintainable by different teams. And the most important here is to let the team choose its own architecture, programming language, tools, and frameworks. It often happens that teams are forced to use one language or technology to avoid “tension”. It won’t do any good. Each micro-service team must be able to pick its architecture, be autonomous of other services.

How to track the performance then? Try using metrics on a per-team basis:

• Resource consumption (CPU, Network, RAM, etc).
• Services reliability (SLA).
• Code quality / Tech dept / Test Coverage.

Also, there are many ways how to set up communication between microservices. Apache Kafka, RabbitMQ, IBM MQ, and other message brokers handle communication between separate microservices by creating queues.

? Tip 2. Increase Roll-out and Be granular

This one needs to be just right to work. If you work on a feature in a microservices team, you’d probably try to develop it for a long time and the rollout and impress. However, practice shows that frequent rollouts with fewer functions are more effective. The reason is that you save time on unnecessary tasks as you only test small pieces and adjust the workflow after. Imagine you’ve spent months on a feature no one likes. Aside from spent cost and time, you get quite disappointed. Smaller teams for each service let test app features for quicker and more sustainable solutions.?

In perspective, Continuous Delivery and setting up DevOps is what we want. The approach automatically tests and pushes each build through the pipeline to production. The fancy name CI/CD pipeline is actually worth considering for microservices or any quick scaling approaches.

? Tip 3. Domain-Driven Design or No?

Of course, you need to consider different ones like Test-Driven Development or Behavior-Driven development (this one is tricky). The most common though is DDD or Domain-Driven Design approach. It won’t work for small apps without many services and content. However, you can use DDD as a base for microservices. The main principle is to solve business issues through code. In an e-commerce app, for instance, the business domain is to process an order. To do that, we would have User Interface (all info for the order), Application layer (leads user between UI screens), Domain layer (all entities and objects), and Infrastructure layer (communication).?

A lot of apps though are only partially using microservice for technical operation micro-services. It’s often a technical decision to keep some functions separate to maintain and fix them quickly. The examples could be:

• micro-service for email generation and forwarding
• micro-service for authorization/permission management
• micro-service for secret management
• micro-service for notification management

Short Thoughts After Main Thoughts

With current trends in software, I could say we will see more microservices or containerized applications. Pay attention to trends like Kubernetes, Docker, blockchain. They can really benefit your app in the future. As for microservices, they are useful when your monolith is literally dying, but in many cases, it’s still alive and fine. Probably there are more solutions like separating services without completely splitting, doing container apps, etc.?

Don’t hesitate to ask if you have questions.

Share your thoughts too ??