I read and studied Uncle Bob Martin's blog post titled "A Little Architecture".
I would say that this is the time of my enlightenment on how to structure software projects.
"Architecture is not about frameworks and databases and web servers..."
Before this period, I had been thinking that software architecture is about how to combine all these frameworks and libraries and tools together to form an application!
Windows Forms for presentation | ADO.NET for data access | SQL Server for database | etc.
ASP.NET Web MVC for presentation | Entity Framework for data access | etc.
Hot Towel SPA Template for frontend | ASP.NET Web API for backend | Entity Framework for data access | StructureMap as DI Container | SQL Server for database | etc.
... have I been putting much of my time and attention in the wrong places!?... I'm not sure. Perhaps this is just part of growing up as a programmer through trial-and-error, with no one personally guiding you.
"The important decisions that a Software Architect makes are the ones that allow you to NOT make the decisions about the database, and the webserver, and the frameworks." — Uncle Bob Martin
Of course I understand that the peak of an enlightenment comes from a series of little enlightenments. So even though this article of Uncle Bob is very special to me, I acknowledge that there are lots of other materials (and experiences) that helped me come into this kind of enlightenment.
I have always been in search for the best way to structure software systems. Now I think I already know the gist of it:
Just do your best to separate the business rules from the other parts of the software system.
Or, to use the words from the blog post “Hexagonal != Layers” by Thomas Pierrain:
divide our software in 2 distinct regions:
the inside (i.e. the business application logic)
the outside (i.e. the infrastructure code like the APIs, the SPIs, the databases, etc.).
We have to separate policy from mechanism in our software systems.
Or from the words of Uncle Bob Martin himself in his book “Clean Architecture: A Craftsman’s Guide to Software Structure and Design”:
All software systems can be decomposed into two major elements: policy and details. The policy element embodies all the business rules and procedures. The policy is where the true value of the system lives.
The details are those things that are necessary to enable humans, other systems, and programmers to communicate with the policy, but that do not impact the behavior of the policy at all. They include IO devices, databases, web systems, servers, frameworks, communication protocols, and so forth.