This article really interests me - mainly because over the last 10 years, I've sort of adopted (independently) a mish-mash of what here is described here as the 'clean architecture', domain-driven design, and the 'ports and adapters' approaches. I have employed these concepts on a dozen or so SaaS products, and the resulting schemes have have worked extremely well, and have been rock-solid frames to work from.<p>However... I think there's a risk in adopting these types of models without having some experienced context in them. Software design has a huge amount of 'art' to it. And, it's so easy to reach the complexity tipping point - where it all come crashing down. For instance, I remember back in the mid-90s when the design patterns book was all the rage. And, shortly thereafter I'd find code just jam-packed with factories and builders and observers and adapters in multiple layers. It was a mess. Similarly, I can see someone reading these and then going out and creating a 'devices' namespace, a 'controllers' namespace, etc. and filling them with all too many classes and interfaces. I can even predict the rise of the 'framework' maven archetype that creates a bunch of extraneous excess.<p>Listen, I've been there and done that, and it just doesn't work well. It just creates a lot of architectural noise. It creates a mess for your development teams. I've learned this the hard way. Trust me.<p>What I recommend is starting very, very slowly. Just like when DI was the rage, and everyone would leap to integrate the most popular DI engine with all its xml configuration files and heavy weight complexity. When, in fact, all you really need at first is a couple of interfaces and a builder class in the entry-point. Don't set out to create an architectural behemoth.<p>That said, I still think a solid 'domain model' should be at the core of it all. If anything, spend a lot of time defining the domain. Work with stakeholders (product managers, subject matter experts, managers, field and support, even developers, etc.) to get it down. Write unit tests that help make the domain very fluent. In my opinion, it's better to have a small core of very well defined domain classes, then trying to boil the ocean. Start small and focus on the quality of the entities.<p>Again, this is just from my trial-by-many-errors experiences.