I’ve spent an inordinate amount of time the past half decade across multiple companies working with very large, long running enterprise systems. Especially in long running, constantly changing systems, you want the code to be easy to understand, relatively painless to extend or modify, and when advantageous, be simple to modernize with updated technology. Unfortunately, the systems I’ve worked on have consistently failed to satisfy these goals.
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 why 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.
@jeremydmiller This is great. I was really hoping to hear more from you on this topic after your last appearance on dotnet rocks. One of the questions that hits home with me has been; Are we following prescriptive guidance just because that is what we were told an "enterprise" application is supposed to look like, or is it truly solving the long term coupling, maintenance and organization needs of a long running project.