Earlier I worked in the monolithic paradigm, then SOA microservices, but come to SOA miniservices - that is a balanced approach to architecture - the mix of both.

Miniservice system looks like this:

Traits.

• Zero-trust principle of microservices helps to support loose coupling. The absence of the zero-trust principle in miniservices helps to support a “stable intermediate form” of the microservices and develop them naturally, substitute/remove microservices on-demand and deploy to a customer as a whole unit of functionality, rather than scattered sometimes unrelated pieces of a process.
• The hierarchy of microservices and miniservices is comprehended faster because of clear and natural relationships. A shared database that is an anti-pattern for microservices is a GOOD pattern for miniservice because helps to implement a holistic unit of functionality that can be used effectively as an independent(self-contained) service. Such independent service covers the whole customer requirement or its rational(considering domain) part that can be connected with other self-contained services to provide developers with a comprehensive WebAPI without redundant management of incomprehensible microservices.
• The event Sourcing pattern of microservices helps to exchange miniservices states without direct cooperation thus without high coupling. API Gateway to provide e.g. protection from SQL injections.

Clarification: it is a type of architecture which helps to design/implement independent self-contain systems. What’s the problem with it? Chaotic complexity that drastically decreases code readability, modifiability, and reliability. What’s the causes of chaotic complexity and how to prevent its appearance(or how to reengineer)?

Cause	Solution
System is divided on components, components on classes not according to the domain knowledge(DDD), therefore with time system structure becomes more confused, thus it becomes harder to introduce changes	To use DDD, describe natural hierarchy of processes, entities and according to this hierarchy divide system on components, components on classes, and classes on definite code constructions that describe a class state and functions
Components and classes has a high logical and physical coupling, therefore changes to one component/class imply changes to the other(i.e. code has rigidity, fragility, viscosity design smells). Important, low coupling is a monolithic approach, not a high.	To remove logical coupling we apply DDD, polymorphism, interfaces, etc. To remove physical - SOA(miniservice/microservice architecture) that establish division of a system on physical services
Data exchange between our and integrated(some distributed system that is made by far located team) systems is unreliable	Usually monolithic systems use CORBA/DCOM. These technologies are great but for teams that communicate a lot. If teams are located far away from each other and has a weak communication, then we can apply SOA and RPC, messaging technology(MOM) between its services
Systems/its components should be written in the same platform/language/etc. Thus to connect with other systems there is a need to find one coded using the same tech stack.	Again, by applying to monolithic system SOA, RPC/messaging we are able to connect(integrate one system with another) systems/components coded using different technologies(platforms, OS, languages, etc.)
Absent or too deep class inheritance tree	Using of DDD and SOA help to understand if inheritance is/isn’t needed

Monolithic system looks like this one:

Conclusions about the monolithic approach Best system is a balanced solution with using:

• techniques applied usually to build a high-quality monolith(DDD, RDD, low coupling and high cohesion, inheritance adopted according to DDD, polymorphism, etc.)
• SOA to a whole system division
• appropriate communication way(File Transfer, messaging, etc.) depending on aims/teams organization
• DDD to describe/code system.

This architecture is a diametrically opposite to monolithic, therefore we can take some if its best traits, mix with monolithic traits to create a balanced solution

Problem	Useful trait
It is hard to comprehend because microservice systems consist of too many parts in contrast to monolithic systems that consist of too small amount of parts	This division principle can be used to divide system on microservices and miniservices(which unite microservices) that will be easier to comprehend, than thousand of unrelated microservices. By the way Higginbotham calls miniservice architecture like a cell-based, this type of architecture is used by Uber company
It is insecure, use time on messaging instead of fast direct “talk” between services on-demand(look at “Enterprise integration pattern” of Hohpe)	Messaging is effective in some cases e.g. we need to integrate remote systems and need a reliable and asynchronous communication. In some other cases we can use synchronous RPC or File Transfer
Has problem with operational complexity because each service is deployed independently, coordinating operations across a path of services is often difficult. Additionally, multiple services may be involved in fulfilling a request, so root cause analysis can be impossible with traditional monitoring tools	The same, messaging is expensive but provides systems with reliability, so every system needs an analysis to understand is messaging if worth it

* has problem with operational complexity because each service is deployed independently, coordinating operations across a path of services is often difficult. Additionally, multiple services may be involved in fulfilling a request, so root cause analysis can be impossible with traditional monitoring tools * has limited environmental control * security threats. Independent microservices are standalone applications that have to communicate with each other. If the infrastructure layers that facilitate resource sharing across services are poorly configured, the result is a suboptimal application with a slow response time. * open Source and Third-Party Code Vulnerabilities” ``For a whole description, please visit https://www.kiuwan.com/overcoming-microservices-architecture-risks/`

Microservice system looks like this:

Conclusions about the microservice approach

• Cons: in hard to comprehend and manage the same as monolithic. Has too low coupling instead balanced and the same with cohesion - it is low instead to be balanced.
• Pros: easily to deploy and share with microservice clients.

Miniservices reasoning Miniservice architecture unite the best traits of monolithic and microservices architecture styles/techniques, and helps to implement a balanced solution. Such solution is easy to understand, faster to modify/remove components, fast to deploy, integrate systems made on different technologies.

• It gives an ability to hold stable intermediate form of the system to comprehend its structure and describe to the next teams who wants to finish the software system we do.
• Miniservice consists of microservices i.e. miniservice is like a proxy class(look at “Object-oriented analysis and design” Grady Booch) that coordinate communication of some passive objects(microservices). This is a SOA architecture that increases a system's transactions reliability.
• We can hold the relative primitives size of microservice and miniservice to cope with domain complexity - we decide what size it has considering responsibility and its sub-responsibilities.
• Microservices (to exchange data in their miniservice) use reliable messaging via the REST protocol.
• Each miniservice or microservie can be made by trusty design/integration/etc. patterns.
• Easier to deploy and host