Skip to content

Transition

Vanskarner edited this page Oct 30, 2023 · 3 revisions

Transition

All of the above layer-based diagrams help to understand the purpose and interaction of each level in an architecture; however, to achieve a more appropriate representation of a system architecture, a component-based approach is required. In fact, the decomposition into presentation, domain and persistence layers can be viewed as components.

To define what the components are, we can resort to the following quotations:

Components are the units of deployment. They are the smallest entities that can be deployed as part of a system. In Java, they are jar files.

- Robert C. Martin (Uncle Bob), Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 2017

A grouping of related functionality behind a nice clean interface, which resides inside an execution environment like an application.

- Simon Brown(Author of the C4 Model), Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 2017

On the other hand, my definition of component is not very far from the central idea of the previous concepts and is partly related to the concepts provided by UML. Thus, I define it as follows:

A component is a self-contained, replaceable unit that encapsulates the functionality of a specific part of the system.

I like to refer to components as the acronym ARE, so I call them "ARE Components" 🤭. The reason is because a component-based approach means:

  • Autonomy: Because it has the ability to operate and be tested independently.
  • Reutilización: Reusability: Because it can be used in multiple contexts and applications, without the need for significant modifications.
  • Encapsulation: Because it hides its internal implementation and exposes its services to the consumer through well-defined interfaces.

These components, whenever possible, define the services they offer to their consumers through provided interfaces and can also specify the services they require through required interfaces. Likewise, the dependency rule remains in force, both in the relationships between components (knowing the role of each component in the system) and in the internal organization of each component (maintaining the separation of concerns).

Clone this wiki locally