![]() To accomplish that use case, we decided to build a front-end client application with React + Typescript. Let’s say we have a use case responsible to send a picture to the server. ![]() Dependency Inversion has a crucial role in that design, as a matter of fact, we only can get the most of Clean Architecture with we know how to implement all the SOLID principles correctly. That’s another crucial point in the Clean Architecture, all cross-layer communication is made through solid interfaces. So, if we need to change any external agent implementation like an HTTP client, we don’t need to change anything in our use cases, just in the HTTP client concrete class implementation. ![]() Our entities and use cases don’t have any external world dependency, the only concern that they have is about the domain itself. The figure below exemplifies how the Dependency Rule works.Īs you may see, all the externals agents point in the same direction, and that pattern may give some benefits to us. We can see that the low-level policies are responsible for things that aren’t specific to our domain but specific for our application, and the application is just the way we choose to solve our domain problem. Here we may put the repositories that connect to our database, the HTTP client that made requests, the presentation layer responsible for the UI, and some components that need to talk with third party libraries for example. In contrast, the less specific the component is, the lower the level will be. The high-level policies are defined as the core of our application, the components that are independent of any programming language or technology, the policies that only need to change when our domain changes, that is, only in very specific cases. The main purpose of the Clean Architecture is the Dependency Rule, this rule is all about the direction that our dependencies should point to, that is, always to the high-level policies. That post will give you a little introduction about Clean Architecture, your main concepts, and a way to implement it, giving us an example of an application build with ReactJS. Thinking about this problem, many solutions have been created and one of these is the “Clean Architecture”, presented by Uncle Bob. Our domain does not need to know what web framework or what database system we are using, these things are just plugins that we may define later. That’s not a criticism with the frameworks and libraries adoptions, they really need to be used, there are a lot of wonderful projects that are here to help us, but we should use them in a way that these tools are adapted to our solution, and not the opposed. Our software needs to be more “Domain Oriented Software” and less “Framework Oriented Software”. We need to keep in mind that these tools are just the path and not the end. With the constant evolution in the software development process and the growing adoption of different frameworks, is becoming very common developers getting comfortable with the structures provided by these tools and leaving aside some principles of good software development.
0 Comments
Leave a Reply. |