[andy_ppp]

This! Service boundaries are vital and almost intractable to design up front as you won’t be sure of your systems’ use cases. I’ve worked on numerous micro services systems and all of them were designed in such a way that data loss and unknown error states were mandatory. Micro services seem simpler, but are actually harder than my methodology “as few services as necessary” + bounded contexts within them. Using network partitions to stop spaghetti code just leads to spaghetti network partitions. The discipline to keep this simple and self contained is the important part.

[radicalbyte]

This is why Domain Driven Design should be mandatory reading for all anyone making decisions on Software Architecture.

[hackerfromthefu]

Unfortunately in actual practise I've encountered significant cargo culting about DDD. Attracts a lot of people with mid level experience who suddenly want to dictate architecture based on theoretical ideals rather than practicalities.

There's no substitute for experience, and specifics of adapting architecture to the context of the problem you're trying to solve.

In one case I wanted to use a technology that actually matches DDD very significantly - but the cargo cultish closedmindedness of the practitioners meant they couldn't even understand how an old idea/tech they hadn't liked or approved was, was actually an implementation of DDD.

The problem there is not DDD, the problem is the people who get closed minded and stuck to their one true way (often without really broad experience to make that judgement call effectively). I've learned that pattern of language of absolutes such as 'should be, mandatory, all' do XXX is often a sign of that kind of cargo cultish thinking.

[radicalbyte]

That's very true, and a problem I've also seen. There are an army of mediocre people who've gone full Cargo Cult with it. Usually comes with a big dose of Uncle Bob: The Bad Parts.