It is very important to look things at a different way when we architect a system or module in the context of software engineering. Especially when we used to do things the 'developer' way. As a software architect, technology stack is like a plugin/tools to accomplish the desired output. This blog post will be discussing on how to visualize the idea on how to architect a system.
Architect need to set in their mind that technology stack is not important, its the least of concern to a successful architect a shipped product. So what is a technology stack ?, We all aware for a software system/application to be considered shipped able, we require some sort like a persistent storage to store data. To tackle this, data storage technology is a stack, there are many technology that address this concern, we have database/blob/files even memory data store. Some of example products build by well known software houses that addressing this type of stack are Redis, MySQL, MSSQL, AzureCosmosDB, MongoDb, Elastic Search and many more. Another example of technology stack might be a web server, this is the least important thing to consider if we planning to build a deliverable software, when i said 'least', it doesn't mean that its not needed, it just mean that it is not important during the initial process of architecting our software. In Clean Architecture book by Robert C. Martin, he addresses this concern, below are a very useful diagram that show how we should initiate our architect process.
Lets address this diagram
Entities - At the core, this is the most important thing to be defined before we start developing our solution, Entities are the model that will be designed to address the business needs, These are the critical business rules. This usually consists of classes/objects with functions/methods. This also might be the concrete object model that will be used throughout our system. Entities is the very core of the circle, and it is very important to point out that these object/classes does not depends on outer layer of the circle but, the outer layer depends heavily on the core ( Entities ).
Use Cases - Use cases is where the business rules come in, this is where software analyst output become realized, all the requirement from stakeholders/customer/user will contribute to building up this layer. This layer usually consists of things like CRUD operations, If Else operation and of course it will be translated from business requirement to appropriate algorithm.
Controllers/Gateways/Presenters - These are some sort like a services ( commonly used in dependency injected application ). Take example presenters, lets assume a part in presenters where its responsible is to return an object that define the result of an unit of operation that has been executed at the use case boundary, depending on the return code from use cases layer, it will instantiate the appropriate presentable object that will be used for the outer layer, this can consists of any type of object depending on our system nature, for example exceptions, operations success object, conflict action object etc etc.
Devices/Web/UI/DB/External Interfaces - These is where the choices of technology stack come in play, depending on how the presenters/controllers/gateways output/input, we may then pick the right stack to address the concern, of course each stack of choices introduce their specific domain objects/concerns.
The Take Aways
From the diagram we must understand that as the arrow moving into the core ( entities ), the outer layer is the most least concern in the architectural process. This would mean that, we as an architect to always design a system where the inner layer is not depending on the outer layer, for example changing the data store stack will not harm the core layers, changing the front end web application ui stack from Knockout to Angular will not harm the core layers. Yes, throughout the development, we do change things, but it is always important to know that, changes in the core layer will impact the outer layer, but changes on the outer layer should never change the core layers, if we found that this principle is not being used, it is a sign that we are not practicing a clean architecture.
Conclusion
It is very important to draw these dependency rules before creating a system, besides leaving it open for changes, it will also adhere testing on each layers.
Published on : 6-Feb-2020
Ref no : DTC-WPUB-000097
Ref : Clean Architecture - Robert C. Martin
Architect need to set in their mind that technology stack is not important, its the least of concern to a successful architect a shipped product. So what is a technology stack ?, We all aware for a software system/application to be considered shipped able, we require some sort like a persistent storage to store data. To tackle this, data storage technology is a stack, there are many technology that address this concern, we have database/blob/files even memory data store. Some of example products build by well known software houses that addressing this type of stack are Redis, MySQL, MSSQL, AzureCosmosDB, MongoDb, Elastic Search and many more. Another example of technology stack might be a web server, this is the least important thing to consider if we planning to build a deliverable software, when i said 'least', it doesn't mean that its not needed, it just mean that it is not important during the initial process of architecting our software. In Clean Architecture book by Robert C. Martin, he addresses this concern, below are a very useful diagram that show how we should initiate our architect process.
Lets address this diagram
Entities - At the core, this is the most important thing to be defined before we start developing our solution, Entities are the model that will be designed to address the business needs, These are the critical business rules. This usually consists of classes/objects with functions/methods. This also might be the concrete object model that will be used throughout our system. Entities is the very core of the circle, and it is very important to point out that these object/classes does not depends on outer layer of the circle but, the outer layer depends heavily on the core ( Entities ).
Use Cases - Use cases is where the business rules come in, this is where software analyst output become realized, all the requirement from stakeholders/customer/user will contribute to building up this layer. This layer usually consists of things like CRUD operations, If Else operation and of course it will be translated from business requirement to appropriate algorithm.
Controllers/Gateways/Presenters - These are some sort like a services ( commonly used in dependency injected application ). Take example presenters, lets assume a part in presenters where its responsible is to return an object that define the result of an unit of operation that has been executed at the use case boundary, depending on the return code from use cases layer, it will instantiate the appropriate presentable object that will be used for the outer layer, this can consists of any type of object depending on our system nature, for example exceptions, operations success object, conflict action object etc etc.
Devices/Web/UI/DB/External Interfaces - These is where the choices of technology stack come in play, depending on how the presenters/controllers/gateways output/input, we may then pick the right stack to address the concern, of course each stack of choices introduce their specific domain objects/concerns.
The Take Aways
From the diagram we must understand that as the arrow moving into the core ( entities ), the outer layer is the most least concern in the architectural process. This would mean that, we as an architect to always design a system where the inner layer is not depending on the outer layer, for example changing the data store stack will not harm the core layers, changing the front end web application ui stack from Knockout to Angular will not harm the core layers. Yes, throughout the development, we do change things, but it is always important to know that, changes in the core layer will impact the outer layer, but changes on the outer layer should never change the core layers, if we found that this principle is not being used, it is a sign that we are not practicing a clean architecture.
Conclusion
It is very important to draw these dependency rules before creating a system, besides leaving it open for changes, it will also adhere testing on each layers.
Ref no : DTC-WPUB-000097
Ref : Clean Architecture - Robert C. Martin
About Author
Comments
Post a Comment