Be careful not to standardize too much. The one common standard everyone adheres to across the organization is a micro services architecture. How each micro service is sub divided into layers depends on the complexity of each individual service.
Software layers are an implementation detail. Layers are not important for consumers of that service, so from the perspective of consumers there is no need to standardize this across the organization.
It is certainly nice for developers if each service has the same layers. Consistency is nice, but not a requirement at this level. One advantage micro services have over a traditional monolithic application is that you can reduce the layers based on the complexity of the service. Fewer layers and less code is easier to maintain. From the perspective of developers across the organization, a standard architecture for all micro services is not desirable, because not every service benefits from the added complexity that more layers introduce.
You must balance consistency with complexity. There is no single rule to follow. My only advice is to not surprise people. Choose the design for each micro service based on its needs and complexity, and if possible do not choose a design that is too unique.
Regardless of how many layers you have, typically the fewer layers the better. It becomes less code to write, test, and understand. That is more beneficial than having each micro service designed the same way.
Rather than enforce a particular design, consider establishing some guidelines:
- Separate your concerns (business logic, data access, UI logic, etc should be separate)
- Practice test driven development
- Utilize Dependency injection and inversion of control.
- This leads to code that is easier to test because you can mock complex dependencies.
Basically it boils down to the basic design principles for software, like SOLID, and other similar buzz words and acronyms.
As an extension of this question, another advantage of micro services is that you are free to choose entirely different technologies for each service. You can choose an object oriented language for one service, choose Python for another because of its math and data science libraries, and choose a functional language for a different service because it is easier to handle concurrency. Some application architectures simply do not translate from an OO language to a functional one. So don't just choose a design that fits the needs of a micro service. You are free to choose the technology as well. Be aware this has a down stream affect on hiring, but depending on the problem, it might be justified to diversify the tech stack.
