Introduction

This section describes the core architecture of AppJars, explaining how the modules are designed and structured. The architecture of AppJars is designed for scalability and modularity, adhering to clean design principles and industry best practices. The objective is to simplify the integration process, providing users with a robust and extensible set of modules. Whether you are new to AppJars or a seasoned user, this section serves as a factual guide to the inner workings of the modules, facilitating informed decisions during the integration process.

Layers

Each AppJar is a set of dependencies that can be added to an existing application, adding specific full stack features. Full stack means that they're divided in layers, so they can be used in different architectural styles in your application:

• Data Access Layer: It covers all the logic related to querying, retrieving and persisting information to external data repositories such as relational databases.
• Business Logic Layer: It contains the pure logic and validations that can be exposed as a services to other layers or business modules. It is pure in the sense that it doesn't use data access or presentation components, it represents how the main concepts or the module are validated, persisted and retrieved from the data access layer.
• Presentation Layer: It handles the user interface of an AppJar. It includes all the views, components and abstractions needed to offer a UX of the functional features.

Architecture diagram showing how an AppJar integrates with existing applications

For the layers to communicate with each other, another important part of the architecture is the usage of a common model. It allows all the layers invoke methods and get results based on a common language representing the main concepts of each AppJar, in the same manner that the application does the same.

Modularization

Inside each appjar the code is divided in different modules that can be categorized in the following types:

• Contracts: They contain a set of definitions of what each implementation can offer. they're usually comprised with a set of Interfaces. This allows the usage on applications following the clean architecture design guidelines. You can depend on then, without the need of having a transitive dependency with the implementation details, frameworks and libraries.
• Implementations: These modules are the actual implementation of the contracts above. They contain explicit dependency with the underlying technologies being used. They can be replaced with different ones depending on the non functional requirements of the system being developed.
• Model: This specific module contains the "language" that the rest of the modules use to communicate with each other. It is sometimes considered as the domain model of the application or module (appjar in this case) being developed.
• Presentation: They contain the code needed to handle the communication with the final user. Basically is a set of UI and components to represent the interaction visually.