This is a great and detailed article, but IMO it (or better: HA) completely misses the point. The challenge is not in separating technical from domain code. It is in how to draw boundaries in the domain to support the evolution of the system. HA is an implementation detail.

I only skimmed article but I think its unhelpful to dismiss everything other correctly defining (sub)domain boundaries as unimportant. IMHO there's a hierarchy of decisions that need to be made correctly: service boundaries .... service architecture = HA, .... method naming....

That‘s not what I said, though. 🤷‍♂️

Describing it as "an implementation detail" sounds like it's unimportant.

Ah, I see. They are important. They’re just not something you shape your project layout around, especially not if doing so subverts your ability to isolate parts of your domain from each other. And yes, I don’t think any of the HA, Onion, Clean et al. things are „architectures“.

Hmm... I think there are different levels of architecture. For example, It's been a while but I've often talked about a microservices-based application having two layers of architecture: The first is a service architecture: services, their responsibilities, collaborations, etc

That sounds like the micro / macro architecture distinction I’ve first heard about from @stilkov. I think HA et al. don‘t even qualify as the latter as they basically define which conceptual layer interfaces belong in and are easily exchangeable amongst each other.