A big organisation has several departments, those departments have several business units and those business units are divided into domain teams. Assuming domain teams are atomic or 2 pizza teams, they work on a domain and generally maintain few micro-services.

All the teams use Java/Spring boot for their micro-services. Now, a classic way to write a typical micro-service exposing a bunch of REST API would be to use "Controller-Service-Repository" along with models i.e. 3-tier architecture. Some teams use hexagonal architecture with ports and adapters.


  • Should this style e.g. 3-tier vs hexagonal be standardised across teams in business units/departments in the company?
  • If yes, why?
  • If no, why?

I know "depends" is always a valid answer, but not expecting it in this context :)


  • 1
    If all those domain specific problems can be solved with one golden architecture (down to the detail you intend to enforce) then, the org has already figured everything out !! The teams are there just to convert the solution into code. Win win for everyone !! Do you see the problem yet ?
    – S.D.
    Aug 26 at 4:53
  • The point of micro services is that you do not need to be bothered with these sorts of implementation details. It is distributed, only dependent on message definitions. Centrally enforcing mundane stuff like implementation style kind of defeats that purpose. Aug 30 at 15:07

2 Answers 2


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.


Be very cautious about trying to apply standards like this across an organisation. I get that you probably want to standardise the separation of concerns (deserialising JSON vs. performing business logic vs. reading from a datastore). You would probably be better off promoting the principles underpinning this architectural style rather than enforcing the style itself. Other people might find other ways to write code while maintaining the same standards.

Plus teams should be able to own their own architecture and not have it prescribed to them by an "architect" from their ivory tower. If they find a different style that works better for their use-case, they should be able to do it, rather than doing it this other way "because this is just how we do it because I said so."

There's nothing more dangerous than an idea, when you only have one. Be open to diversifying your codebase, while maintaining sensible engineering principles to ensure quality.

  • "not have it prescribed to them by an "architect" from their ivory tower." I've had to deal with that, it was (still is) a nightmare. Aug 30 at 17:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.