[LarsDu88]

Lets step back a second. If the rationale behind adopting microservices for everything is PURE orgitecture rather than software architecture, then that's not really a rationale at all.

Instead of having one instance, you now have dozens of little service fiefdoms plus all the added network I/O overhead associated with that.

The principled approach is really to simply not do that, for the basic latency costs. I mean, did World of Warcraft, which is way more impressive than 99% of all the little django apps out there in corpo world run on a gajillion microservices? Fuck no

[Too]

If you follow the authors advice you would be tricked into believing monoliths like Photoshop, Excel or any AAA-game could only have been written by a single team only. That couldn’t be further from the truth. There are like 100 other ways to create interface boundaries than carving out microservices.

Microservices is a deployment strategy, not a tool you use to reinforce Conway law, a law that you actually want to defuse more often than follow, to not get your product stuck into your old org chart.

[chatmasta]

Maybe WoW didn't run on Microservices, but you can bet the project was divided into a bunch of different fiefdoms. Just they were separated at the interface level rather than the network level. Same concept though.

Ultimately if you've got different teams working simultaneously, they should be working on non-conflicting features. Microservice is just one architecture that develops within this constraint. You'll never get anywhere if everyone is working on the same interfaces with no separation of concerns. So where should the separation emerge, if not along the same lines as the existing IRL separation? Conway's law is not a coincidence; it's an inevitability...

[IshKebab]

Yeah but "non-conflicting features" can be at the level of an individual task. It doesn't have to be an entire component. The best projects I've worked on were ones where anyone was allowed (and encouraged!) to work on any part. It helps people learn, spread knowledge, prevents boredom, reduces the number of "critical" people.

The worst projects I've worked on (including my current one) had components where people "owned" them. They fight against outside input and treat "their" part as a little kingdom that they rule. It's worse in almost every way.

Obviously there are limits - at some point your project is big enough that you have to have some specialist individuals and teams, but it's wise to avoid that as much as possible.

[c048]

This is what you get when all you talk about it the positives, especially to new programmers or students. It's not about the why, but only if you do or do not.

I'll die on this hill, but DDD can be put right up there with microservices as a solution to a certain type of problem being sold as THE solution.

[FLT8]

I'm interested to hear more about your views on DDD - especially if you have examples where DDD has been actively harmful.

Usually my advice for anyone thinking about building a new piece of software for a particular business goal is to a) run an event storming workshop with a group of domain experts to help get a really good idea of events, actors, commands, information flow and clusters of behaviour, and then b) run a second pass where you think the domain through in terms of transactional boundaries and DDD aggregates, and then c) do a third pass where you think specifically about security constraints and how they can be met.

It's an expensive exercise in terms of time taken up front, but having completed it, hopefully the team have gained enough of an insightful understanding of the domain that they won't make silly hard-to-reverse mistakes like needing transactions that span service boundaries, or building demonstrably distinct domains which share similar concepts into uber objects spanning those domains, or having one service depend on information from multiple other services in order to apply required security constraints.

Anyway, TLDR is I have found DDD and DDD-adjacent methods extremely helpful for thinking through designs and making app architecture decisions.

[Sankozi]

Looking only from technical perspective, microservices are worse than monolith almost every way you can measure. The biggest benefit of microservice architecture is that it handles multiple teams better than modular monolith. This is good enough rationale if you want to have team independence and clear separation of responsibilities and you can accept all technical problems microservices bring. If you cannot accept such problems (like in case many desktop apps and at least in some part of WoW backend) you just need to select something that will work with your constraints - usually it is modular monolith architecture, sometimes something more exotic.