Vertical decomposition. Creating cohesive services
One of the biggest misconceptions about services is that a service is an independent deployable unit, i.e., service equals process. With this view, we are defining services according to how components are physically deployed. In our example, since it’s clear that the backend admin runs in its own process/container, we consider it to be a service.
But this definition of a service is wrong. Rather you need to define your services in terms of business capabilities. The deployment aspect of the system doesn’t have to be correlated to how the system has been divided into logical services. For example, a single service might run in different components/processes, and a single component might contain parts of multiple services. Once you start thinking of services in terms of business capabilities rather than deployment units, a whole world of options open.
What are the Admin UI, Admin Backend and Website UI, Website Backend components? They basically act as containers of services. They are maintained by their own teams and their sole purpose is to coordinate between services. These components are business-logic agnostic.
Avoiding Microservice Megadisasters unsure about the approach to search and data duplication
Microservices and Rules Engines – a blast from the past
"search engine, not search service" "allows each microservice to put a component into it, and the search engine will run that set of rules" "what we are talking about here is not the whole microservice, but the search component of that service" "that way, the search engine doesn't need in and of itself access to all of that data directly"
Don't build a distributed monolith
"Don't couple systems with binary dependencies"
Alas this seems to go against the "thinking of services in terms of business capabilities rather than deployment units" principle. If the deployment is intertwined, is seems that there will be binary dependencies.
The entity service antipattern
Five pieces of advice for new technical leads
in general, re-organizing the architecture of a system is usually possible - if and only if - the underlying data model is sane.
What is the convention for addressing assets and entities? Is it consistent and useful for informing both security or data routing?
What is the security policy for any specific entity in your system? How can it be modified? How long does it take to propagate that change? How centralized is the authentication?
If a piece of "data" is found, how complex is it to find the origin of this data?
What is the policy/system for enforcing subsystems have a very narrow capability to mutate information?
More than concentric layers The Software Architecture Chronicles
Managing the Complexity of Microservices Deployments
Designing Microservice Architectures the Right Way slides
To Test A System, You Need A Good Design Shunt pattern Two-level test suites?
For a test environment, you can inject an “In-Memory Data Source.” For production, you can use the “HTTP Server Data Source.”
How Contract Tests Improve the Quality of Your Distributed Systems
SOLID Architecture in Slices not Layers
For too long we've lived under the tyranny of n-tier architectures. Building systems with complicated abstractions, needless indirection and more mocks in our tests than a comedy special. But there is a better way - thinking in terms of architectures of vertical slices instead horizontal layers. Once we embrace slices over layers, we open ourselves to a new, simpler architecture, changing how we build, organize and deploy systems.
Scaling without cross-functional teams
Growing Object-Oriented Software, Guided by Tests Without Mocks Unit testing anti-patterns: Structural Inspection