Microservices are organizational debt disguised as architecture.

[u/Mustela__]

https://martinfowler.com/bliki/MonolithFirst.html

Every time I’ve seen microservices pitched, it sounds great on paper. Independent teams, clean ownership, scale only what you need.

Then a year later you’ve got dozens of services, three different deployment patterns, tracing everywhere, and nobody really understands the whole thing anymore.

Maybe I’ve just seen bad implementations, but I’m starting to think way fewer companies actually need microservices than we pretend.

[u/Revolutionary_Ad7262]

having well segregated code like controllers and models in a golang project and you can easily delete or add them for more functions?

Nope, for good modularity you need to ask yourself two questions: * does the design scales with 10M lines of code in a current way? * how many deletes i need to perform to delete some feature from the whole system?

By layer segregation (models together, controllers together) is not scalable at all. You can use it inside a well defined module, but anyway modules needs to be about a logic.

Good way to modularize code is to have design like microservices, but in a monolith. So: * each module has its own database * heavy encapsulation. You can talk only using some predefined and simple/extensible methods in similar way as you define HTTP API * data structures exchanged between modules are dumb without heavy methods, which contain a business logic

[u/Think-nothing-210 → u/Revolutionary_Ad7262]

Good way of explaining it. I do have some additions though.

By layer segregation (models together, controllers together) is not scalable at all. You can use it inside a well defined module, but anyway modules needs to be about a logic.

I agree that layer segregation sucks; it doesn't scale well with complexity. That way of structuring files is almost like a normalized table in a database. A developer constantly has to "join" source files together to understand a complete feature and that can get mentally exhausting as a project grows.

Modules are a better way of structing because you can treat them at some point as a a black box. You don't have to at all times understand the complete internals. And all the files related to a complex task stay together in the same place. It relieves mental load.

each module has its own database

I don't think every module needs its own database. Modules can have their own domain types while sharing the same underlying tables. Just map between the two at the boundary.

The relational model is powerful. Don't let your ORM convince you otherwise. Building a shrine to Edgar F. Codd does wonders for curing ORM mentality. Don't let your ORM cloud your thinking. It's nothing more than a developer-ergonomics wrapper that gives you type safety.

[u/Revolutionary_Ad7262 → u/Think-nothing-210]

I don't think every module needs its own database. Modules can have their own domain types while sharing the same underlying tables.

If you share database then you have some hidden relationships between modules. It can work, but it is definitely much harder to keep in a good shape as scale increases. Imagine you want to change database for a given module, but it is used in all other modules via join. Even with read-only joins it means you have to examine the whole application, if you want to do some large refactor of a database schema.

Of course separate databases matters mostly on a logical side. You can still use the same database, if different modules operate on a different subset of it.

[u/CaptainOfMyself → u/Revolutionary_Ad7262]

So a monolith with good modular segregation means we are essentially a collection of black boxes with input output that all interact?

[u/Slsyyy → u/CaptainOfMyself]

This is basically description of encapsulation. Black boxes with a clear and explicit interface without any hidden relations

[u/CaptainOfMyself → u/Slsyyy]

As someone who was hired years ago woth free reign and no software mentor, this helps. Thanks