Design and Objectives

Software Architecture involves design. Design involves understanding the concept of or proposal of a system. The objective of software architecture is to minimize the efforts to create and maintain systems.

Structure of Systems

Systems are everywhere, they are within our bodies, in electronic devices, and we are constantly interacting with various systems that we might not realize. See the figure below that contains the car brake system. This system contains layers or separate parts that interact with each other to reach the end goal of controlling the speed of the car.

The design or architecture of systems tends to display the objectives of what it intends to provide.

Details

Many newcomers to the IT world learn by practice, this means that they learn by problem solving, like writing lines of code to solve a specific problem. Therefore, many times the software architecture is not taken into consideration. Many complex software exists today without proper design or architecture, the question is how long it will survive or evolve to fit market needs.

When analyzing code, you might see something like HTML, CSS, and JavaScript. You might run into a mobile or desktop application, then you might work on the data access layers where you connect to the database and retrieve data. The User interface, data access frameworks are all details of the application.

Databases

The modeling of the database schema has architectural implications, however the frameworks behind the data access for CRUD operations do not. Therefore, your code should not have dependencies on the frameworks behind the data access technology.

Web

The web is a (GUI)graphical user interface. With time the frameworks of GUI can evolve and change. Within Microsoft Technologies there is a clear evolution of frameworks within Microsoft frameworks from classic ASP to Web Forms then ASP.NET MVC and Web API's. Therefore, since the web can evolve, when architecting applications there should be limits to the GUI and the business logic of the application also known as the core of the application.

Frameworks

Many frameworks today are open source and that's great, but it does not mean that frameworks will adapt to all your applications needs as time passes. Some frameworks will make your applications tightly coupled when it comes to setting them up with derived classes etc.

Risks of adopting frameworks

1. They might violate your architecture standards and dependency rules.
2. They might not evolve to fit your needs with time.
3. New and better frameworks might become available.

You should not ignore the use of framework, but you should avoid coupling a framework to your application. Frameworks should be part of the details of the application and discarded/replaced if necessary.

Business Rules

The business rules of an application are what typically generate value to organizations. Business rules are tied to the business and systems facilitate the validation of these rules. Let's suppose that we have a banking organization that opens bank accounts to its customers and a requirement to open a bank account is a social security number. If those rules are used within a software or not it is still a valid rule.

Entities

When working with software data is generically being transferred through objects and business rules are validated. These objects can be associated with entities. The entity object contains the core business rules data.

Use Cases

Let's suppose that in the banking application, once an account is open you could choose to have a premium or black card. However, the rules for that are that your credit score needs to be higher than 750. In that case you have rules that verify the credit score based on input data, processed information, and output, this is a use case. Use cases differ from the core business data since the rules are specific to the application.

Clean Architecture

Based on the analysis of the previous sections we have a couple of takeaways.

1. Don't depend on frameworks - Software architecture should not be tightly coupled to frameworks. This allows for the use of frameworks as a replaceable tool.
2. Testability - When the core and business logic of the application has few dependencies it isolates itself and facilitates the application of testing principles.
3. User interface tends to evolve - The web has evolved and could be changed to desktop, mobile or other future interfaces. Not having your core or logic of the application tied to the user interface could be of great value.
4. Independence of connected services - Services like databases, message bus, email provider can evolve and change. Keeping these layers away from the core functionality can be beneficial.

The figure below contains a version of clean architecture. Clean architecture may vary. Some versions may have more or fewer layers depending on the design and necessity. To make things simple I create a 3 layered architecture.

The main rule for this architecture is the dependency rule. The core or center of the application cannot depend on external layers and so on. Core is independent, use case may depend on the core and the details may depend on any layer. This separation of concerns allows one to follow the takeaways described in the initial part of this section.

Conclusion

Clean architecture is not the ideal architecture for all applications. It is important to understand the fundamentals and different patterns and variations that come with this architecture and analyze if it makes sense for the system that you are working on.

Since this is only an introduction, simplicity is key. Following the rules for each of the layers will allow independence of frameworks and UI and facilitate unit testing the rules of the application. There is a lot more to clean architecture and if you want to dive a little deeper, I suggest reading the clean architecture book by uncle bob or for practical experience doing the course reference on this post.

References

1. Martin, Robert C. "Clean architecture".
2. Clean Architecture Fundamentals