There is a lot of hoopla ongoing in the software world with the term 'Clean code architecture'/'Onion architecture' introduced by 'Uncle Bob'. Here I would like to illustrate on it, without all the hoopla!
Over the years I have developed several apps using the Clean code architecture - and I feel it can be suitably described as an extension of the best practices preached by several of the 'dyed in the wool' enterprise frameworks like Spring. So lets get on with it:-
What is it?
As I said its a bunch of architectural best practices which has long been promoted in the Spring (and other enterprise-y) web development community. Its an architectural pattern based on the SOLID design principles and incorporates a layered architecture, where each layer interacts with the layer below it and pushes data to layer above it.
What do I gain from it?
Well finally this might be your fool-proof way to develop SOLID code. What you do is develop code based on your application 'use cases' and group them together based on clearly defined responsibilities. Usually the components can be grouped in the following categories: -
- Views - its the presentational layer and is strictly responsible for displaying the 'formatted' data and nothing else.
- ViewModels - its the model for the view, to illustrate further its a set of data structures, that contain formatted data to be displayed by the view.
- Controllers/Presenters - they are the conduit/pipe between the views and the rest of the system. They inform the application of user interaction and push updated system data back to the view in a suitably formatted format.
- Interactors - they hold the application specific use cases and manipulate the system data in accordance with the requirements of the specific use case.
- Repositories - this is where the system data is stored, usually every entity has its own repository and the repository stores the system data related to that particular entity.
- Entities - they are the business objects of an application, e.g. a Customer entity in a Billing system etc.
Its also very important to observe the Dependency rule, items in the list above depend on items below in the list and not the other way. Just follow the arrows in the picture below, they clearly illustrate the dependency flow. Its always pointing inwards.
As like anything else I would forbid you to copy it blindly, but rather soak it in, understand it, and then use what works for you - you can certainly use this document as your guideline. Also please ensure to visit the several other links in this document to learn more about it.
কোন মন্তব্য নেই:
একটি মন্তব্য পোস্ট করুন