Hacker News Reader

Comment by me551ah | Hacker News Reader

I'm just curious if there is a middle ground somewhere?

On one end you have a giant monolith. All services rolled into one which includes your API, Middle ware and then Database.

One the other end you have microservices which bundle services into individual distinct units with each service being responsible for its API, middleware and database.

Are there any preexisting patterns which seek to combine these two and come up with an architecture which is midway between those two. A few months ago I had read an article about Data Oriented Architecture on HN which comes close though I'm wondering if there are others.

View on HN

> which includes your API, Middle ware and then Database

Layered microservices are an antipattern. In most cases, functionality is best divided by domain.

This is why I struggle with microservice architectures. It seems like there is a basic contradiction. On the one hand, it's vitally important that the microservices are carved into the correct modules otherwise you get a nightmare of operational complexity where simple functional changes require coordinated changes across multiple services. But defining the correct way modules requires a bird's-eye architectural view of the entire system, which seems contradictory to idea of self-organizing, independent teams. I can see how it works when the right way to divide things up is obvious or when you are dealing with IaaS or PaaS services, but in a complex business domain who decides how to carve things up?

> In most cases, functionality is best divided by domain.

So, SOA?

Service-Oriented architecture? This node.js framework specifically implements it: https://feathersjs.com (as an example)

There's what DHH calls the 'Citadel' architecture, which is basically you carve off a few small chunks from your monolith where needed and call them 'outposts':

https://m.signalvnoise.com/the-majestic-monolith-can-become-...

Reply on news.ycombinator.com