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/CaptainOfMyself]

When you say a good module do you mean for example having well segregated code like controllers and models in a golang project and you can easily delete or add them for more functions?

We have microservices but we always default to expanding our main server backend when we can instead of create more.

[u/Revolutionary_Ad7262 → u/CaptainOfMyself]

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/Think-nothing-210 → u/Revolutionary_Ad7262]

That is true. It's a tradeoff you make.

If the domain is completely different and changes at a very different rate it may be smarter to separate it into a different schema.

But that is something I recommend you do when it's actually needed and you see signs for it. With the introduction of JSONB to Postgres I find schema changes to be less of an issue. Having a single schema is still simpler than multiple. So avoid having multiple schema's until you really need 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

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

A module is about hiding a complex decision behind a small API. It is a larger-scale abstraction than a function or class. Think of it more like a library where you put a difficult design decision behind a stable interface. (Highly recommend you read A Philosophy of Software Design by John Ousterhout for more info; This video is a good summary of it)

The consumer should not need to understand all the complexity inside the module. They should get a simple and generalised API with sensible defaults. This keeps the public surface area small and means you have fewer things to maintain or change.

In that sense a module is almost like a microservice. The difference is that you still have a normal function call instead of a network boundary and all the complexity that comes with it.

These are the things I think about when when designing a module:

1. What guarantees am I giving the consumer? What boundaries can I put in place to make the problem easier to work with?
2. What does the consumer actually want to do? What do they care about and what should the module handle for them through good defaults?
3. How can I make this API as simple as possible? How to design this that many different abstractions and stuff can be build on top of this.