I agree with most of these practices. In a lot of the documentation about these things the warnings not to apply them prematurely exist and one must always weig

I agree with most of these practices. In a lot of the documentation about these things the warnings not to apply them prematurely exist and one must always weigh pros and cons, etc. It is easy to fall into the pitfall of having found a hammer and seeing nails everywhere after wading through reams of cool architecture patterns. But there is maybe a downside to the advised refactoring processes as well. In a way you exchange consistency, predictable and repeated code structures, for less structural complexity but on an ad-hoc case-by-case basis because everywhere you make different choices to how far you take the abstraction. This creates another way that a codebase can be hard to comprehend to newcomers or when returning to it much later. "Why do they use this pattern here, but not over there?", "Why is this an interface and that not?", etc. Similar ways of doing things become less recognizable. It is comparable to the discussion that applying SOLID generally leads to more boilerplate, which requires discipline and results in more 'moving parts' to pay attention to, versus a much more practical approach that is less time-consuming in the short term. In this latter approach 'continual refactoring' is needed to avoid it starts to bite later on. So I'd say: handle decision of 'prematurity' of abstractions with care too, before you remove them. The Vertical Slice Architecture is a good approach. And a good folder structure and file naming convention can make tracing interfaces to the implementation that is invoked a lot easier as well. PS. It might be cool to have those sticky note diagrams being more directly tied to the code with some tool, as a way to navigate and delve into it. And along with that suggest more elaborate alternative design chunks that can be 'swapped in' if refactoring to higher abstraction is warranted.