Ironically enough though, my judgment is that the code in these systems has been hard to understand, extend or change, and modernize because they had all adopted much of the very industry conventional wisdom about how to build large, maintainable systems.

In particular, I want to demonstrate and explain how I think that prescriptive, layered architectural styles like Clean or Onion Architecture can actually cause harm in larger systems. I also want us to train our sights on how teams attempt to hide the actual persistence technology with “repository” abstractions and why I also think that’s harmful. I want us to shine a light on how teams fall down a trap of organizing code around business entities or data storage in ways that helps make the code in big systems hard to work with.

And of course, we’re going to talk about alternatives, or at least ways to ameliorate the potential problems with prescriptive architectural approaches. In particular, I’m going to show the shift to vertical slice architecture approaches for organizing code. I’m also going to examine ways to reduce code ceremony to improve code readability and use that to show the negative tradeoffs of using approaches like the Clean Architecture that mandate some elements of code ceremony to “force” developers into a consistent approach. And finally, we’re going to examine whether or not “consistency” should be a first class goal in code organization or architecture.