Clean Architecture personal Analysis


Created in mid-2012 by Robert Cecil Martin ("Uncle Bob"), Clean Architecture has as main purposes to be independent of frameworks, easily testable, regardless of the user interface, that is, the user interface can change at will without this reflects in the rest of the system, be independent of database, since it maintains all business rules in the application itself and, finally, be independent of any external agent, and the business rules do not "see" the " outside world ".

Clean Architecture



Though these architectures all vary somewhat in their details, they are very similar. They all have the same objective, which is the separation of concerns. They all achieve this separation by dividing the software into layers. Each has at least one layer for business rules, and another for interfaces.
Each of these architectures produce systems that are:
  1. Independent of Frameworks. The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints.
  2. Testable. The business rules can be tested without the UI, Database, Web Server, or any other external element.
  3. Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.
  4. Independent of Database. You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.
  5. Independent of any external agency. In fact your business rules simply don’t know anything at all about the outside world.
The diagram at the top of this article is an attempt at integrating all these architectures into a single actionable idea.

The Dependency Rule


The concentric circles represent different areas of software. In general, the further in you go, the higher level the software becomes. The outer circles are mechanisms. The inner circles are policies.
The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in the an inner circle. That includes, functions, classes. variables, or any other named software entity.
By the same token, data formats used in an outer circle should not be used by an inner circle, especially if those formats are generate by a framework in an outer circle. We don’t want anything in an outer circle to impact the inner circles.

Entities


Entities encapsulate Enterprise wide business rules. An entity can be an object with methods, or it can be a set of data structures and functions. It doesn’t matter so long as the entities could be used by many different applications in the enterprise.
If you don’t have an enterprise, and are just writing a single application, then these entities are the business objects of the application. They encapsulate the most general and high-level rules. They are the least likely to change when something external changes. For example, you would not expect these objects to be affected by a change to page navigation, or security. No operational change to any particular application should affect the entity layer.

Use Cases


The software in this layer contains application specific business rules. It encapsulates and implements all of the use cases of the system. These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case.
We do not expect changes in this layer to affect the entities. We also do not expect this layer to be affected by changes to externalities such as the database, the UI, or any of the common frameworks. This layer is isolated from such concerns.
We do, however, expect that changes to the operation of the application will affect the use-cases and therefore the software in this layer. If the details of a use-case change, then some code in this layer will certainly be affected.

Interface Adapters


The software in this layer is a set of adapters that convert data from the format most convenient for the use cases and entities, to the format most convenient for some external agency such as the Database or the Web. It is this layer, for example, that will wholly contain the MVC architecture of a GUI. The Presenters, Views, and Controllers all belong in here. The models are likely just data structures that are passed from the controllers to the use cases, and then back from the use cases to the presenters and views.
Similarly, data is converted, in this layer, from the form most convenient for entities and use cases, into the form most convenient for whatever persistence framework is being used. i.e. The Database. No code inward of this circle should know anything at all about the database. If the database is a SQL database, then all the SQL should be restricted to this layer, and in particular to the parts of this layer that have to do with the database.
Also in this layer is any other adapter necessary to convert data from some external form, such as an external service, to the internal form used by the use cases and entities.

Frameworks and Drivers


The outermost layer is generally composed of frameworks and tools such as the Database, the Web Framework, etc. Generally you don’t write much code in this layer other than glue code that communicates to the next circle inwards.
This layer is where all the details go. The Web is a detail. The database is a detail. We keep these things on the outside where they can do little harm.

Analysis

I created a simple example application, using this architecture, which led me to having to create a class for data entry (request), an entity class (domain) and a class for data return (response), and an adapter to convert this data.




 


This would solve a simple problem, if I have an input and  I have to return different output data, in my case that would be the only problem that this architecture would solve.

Conclusion

In my case this only increased the complexity of the code, almost without the need to use those classes that I mentioned above, that is, an excessive complexity and also redundancy of code that would imply more coding, testing and maintenance.

But it is an effective approach in specific cases, as I quoted input data, different from the return data.

My source code is here: SpringMongoCleanArchitecture

Source: The Clean Code Blog, by Robert C. Martin (Uncle Bob)


Comentários

Postar um comentário

Postagens mais visitadas deste blog

Simple Application Microservices and MongoDB using Clean Architecture

Imagem
Simple Application Microservices and MongoDB using Clean Architecture Created in mid-2012 by Robert Cecil Martin ("Uncle Bob"), Clean Architecture has as main purposes to be independent of frameworks, easily testable, regardless of the user interface, that is, the user interface can change at will without this reflects in the rest of the system, be independent of database, since it maintains all business rules in the application itself and, finally, be independent of any external agent, and the business rules do not "see" the " outside world ". For start my application I studied some frameworks before choose some, at the end the choose was not for performance, just for an example I choose the fasted way to developed, easy understand, easy codification and quick production instead of best performance. You can ask me, why I would choose facility instead of performance ? First question, do you really need a truck...
Leia mais

Adaline - Adaptive Linear Neuron

Imagem
Just continuing with my explanation about Artificial Neural Networks in a simple way. The Adaline  ( Adaptive Linear  Neuron or later  Adaptive Linear Element )  network, proposed by Widrow and Hoff in 1960, has the same structure as the Perceptron, differentiating only in the algorithm of training. She is an adaptive network, with the Inclusion of a pioneering algorithm for the training of  multi-layered networks, the training algorithm of the Delta rule, the Delta rule algorithm is based on the method of least squares, she has a smoother learning method. Their goal is Perform local iterations to get the function and thus set the values of the weights  when the minimum was found. Through an arbitrary point (vector of weights started randomly), the algorithm runs, at each iteration, the surface of the error function towards the point of Minimum. Adaline is a single layer neural network with multiple nodes where each node accepts multiple...
Leia mais

Akka vs. Spring Reactor personal comparison

Imagem
Akka vs. Spring Reactor personal comparison: I used for both a mass of Fake data of 200000 records for each. Both use the Reactive Streams Specification (Reactive Streams) Reactive Streams is an initiative to provide a standard for asynchronous flow processing with non-blocking return pressure. This includes efforts focused on runtime environments (JVM and JavaScript) as well as network protocols. What we want is asynchronous and non-blocking. A group of developers of companies like Netflix, Pivotal, RedHat, etc. met and converged to something called The Reactive Streams Specification.   Akka framework Akka is an Opensource framework. Akka is implemented from the agent model (originated in 1973 by Carl Hewitt), which provides a model for dealing with concurrent computing. Akka, the unit of execution is the Actor and his microservices are built as actors. An actor is lightweight and there may be sev...
Leia mais