Could you talk about pragmatism in Architecture?

Could you talk about pragmatism in Architecture?

I recently published an edition of Clean Architecture on iOS, "Principles and Good Design Practices Applied on iOS."

It has been quite a gratifying job because it has allowed me to consolidate and organize the information obtained throughout the execution of multiple projects on iOS about best practices and applied architectures.

In mobile solutions, the reference architecture known as Clean Architecture has been assimilated quite well.

 I will not go into details of the motivations for which this style of architecture has become so crucial in the design of mobile solutions, but I do want to share an excerpt from one of the topics covered in the book:

Pragmatism in Architecture?

There are aspects of the architecture that can be negotiable or, in other cases, postponed. However, there are other aspects of architecture that cannot be omitted, much less ignored. In these terms, the architecture of the solution is pragmatic only up to a specific limit. Beyond that, it is no longer Clean Architecture or even any Architecture. 
It is the weighting that a team must always manage to protect the solution.

What could be the non-negotiable aspects of Clean Architecture? 

Firstly, the dependency injection manager. A robust solution necessarily requires a mechanism to manage dependency injection to achieve the practical application of control inversion. That is an element that must be included in the first version of the application.

Secondly, it is more a definition than a component and corresponds to the three layers that must be present as a minimum: Presentation, Data, and Domain. From this minimum of three layers, the solution could add the ones it considers necessary. Options for organizing these layers are discussed in the organization of the project chapter.

Thirdly, there must be a design pattern in the presentation layer and a design pattern in the data layer. For the presentation layer, there are several candidates (MVC, MVVM, MVP, MVI), as shown in the pattern chapter.

In the data layer, the Repository pattern is recommended. Some implementations might propose using a Datasource directly, however in Clean Architecture, and such delegation is not negotiable, Repository must be present.

In fourth place, a component that could generate controversy because it is a mediator component (like Repository) is UseCase. Some would omit it to integrate the Repository directly with the ViewModel, but in Clean Architecture, this component is non-negotiable. It is a crucial piece in the design. In some implementations, they prefer to call it Interactor.

Also, in fifth place is a configuration that must also be included from the application’s start. It is the configuration applied by the Plugin pattern to manage the solution’s variants. The continuous integration and process system use these same settings.

What are the aspects that could be negotiable?

Through refactoring and as the solution requires it, new capabilities could be included to strengthen the application, optimize processes, and improve quality attributes of the solution.

The Mappers. Including a Mappers Strategy, as described in the Cross-Border Mapping section, carries multiple benefits in cross-layer communication and information transport.

A Caching Strategy. Although the implementation of the application can start without a strategy to manage local information and remote information, it is appropriate to incorporate a mechanism at an early stage that allows integrating the benefits of an offline mode design. This ability could improve quality attributes, such as performance and availability. The chapter Strategies for managing local and remote information is entirely devoted to this topic.

Another set of components that could add flexibility in applying application or presentation logic are the Value Objects. This pattern can be added at a later stage in those functionalities that contain a complex set of business rules and validations. More detail is presented in the section When to decide between Entities or Value Objects.

And last but not least, Coordinator pattern, which in its discretion (in my opinion), should be included from the initial version of the application. It is an improvement that increases the testability of the Views, and the navigation flows between them. It also provides the flexibility to configure navigation flows by facilitating, for example, AB Testing. The description and application of the pattern are found in the Coordinator.

Next Post »
Thanks for your comment