[kybernetikos]

I think you're right to be skeptical that microservices are required in order to stop code becoming spaghetti.

I think of it as all about what kind of boundaries you choose to put in your code and where. https://hivekit.io/blog/mesolithic-architecture/ The blog calls it 'mesolithic' architecture, but I almost wonder if 'gabion' architecture might be better - separate small rocks held together by a metal frame, forming a single architectural piece.

The principles of good architecture do not require you to make your boundaries network or process boundaries, but they do require that you have boundaries and that you're careful when and how you cross them.

[berkes]

Bounded domains, as Evans calls them in DDD.

Indeed, how these domains communicate is rather irrelevant. It can be HTTP, injected objects, closures or functions, a message bus, an event store.

I've worked on a few actually good Rails apps (out of hundreds of abysmal to just meh ones). Some just put all he bounded domains in libraries (gems, railties), some by pure message passing, one through sheer discipline to not ever add that has_many that would cross a domain boundary.

Microservices are just one, very specific way to erect and enforce bounded domains. But there are many more.

I guess, though, that in practice, "monolith" means "lack of any decoupling or domain boundaries". At least, to many it apparently does.

So then there's still a large group of architectures that aren't exactly microservices (http communication, isolated runtimes and processes) but aren't monoliths either.

What would those be called?