Don't Build Distributed Monoliths! When building microservices, make sure to avoid the anti-pattern of building distributed monoliths. Here is some advice on best practices.
Microservices have been a hype topic for the last several years, and many developers are using this concept when structuring and implementing code nowadays. However, as always, every technology has advantages and disadvantages. So when I’m asked whether microservices architectures make sense, my answer is: It depends!
Cloud-native architectures and microservices clearly have a lot of benefits. One benefit is the simplicity of smaller modules. For example, I used to work on a product that had grown for many years and it had several million lines of code. Developers were scared to change even a few lines, since the effects were not predictable. As a result, productivity was very low. Smaller services would certainly have helped a lot to handle the complexity.
Because of this, breaking down monoliths in multiple microservices might make sense. The key question is how to do this.
One anti pattern I’ve often seen is to have too many microservices, where each microservice basically represents a single entity with typical CRUD operations, in many cases with pure RESTful APIs. In order to communicate between microservices, synchronous REST invocations often are used.
This does not lead to service-oriented architectures, but to distributed monoliths. There are too many dependencies, which are even harder to handle in distributed environments than in monoliths.
One approach that helps to define microservices is domain-driven design. Additionally rather than using microservices, another option is to use macroservices, which are more coarse-grained. Especially when applications need to handle transactions these approaches should be considered.
In this article, we define the core concepts around domain-driven design, explain them, and highlight the advantages and downsides of the approach.
Domain-Driven Design (DDD) concept was introduced by first Eric Evans in 2003. The concept of microservices did not exist at that time. So basically DDD was introduced to solve the problem of a large monolithic code base.
In this blog post, we are going to discuss how to Microservices powered by Domain-Driven Design. Finding it difficult to model boundaries of system’s microservices, slowed down by Tech complexity then Domain-Driven Design DDD is likely useful to your Team!
"Microservices Design Patterns - Microservices Architecture Patterns" talks about the top design patterns you can use to build applications. You will learn: Why do we need Design Patterns? What are Design Patterns? What are Microservices? Principles behind Microservices and Microservices Design Patterns
Domain-Driven Design (DDD) provides much of the strategic design guidance that we can use to determine the boundaries around and interactions between Microservices in our solutions. DDD also follows up with tactical design patterns for your business logic. In this session we'll take a look at some of these patterns and how EF Core naturally,