Mantra is a framework designed so that the funcionality of any project can be organized in small components.

Why? Because while the project is getting bigger, when including new requirements or evolving current components, will be easier to work with the project and evolve it, reducing costs and tehcnical debt.

At the time of writing this, Mantra site is based on 80 differents components with no more than 1 KLOC by each at the most.

How to decide the way you distribute your functionality? Easy, remembering SRP principle (single responsability principle), in Mantra culture we usually say that 1 component = 1 specific functionality.

This is the key for building big projects that evolve considerably over time with components highly decoupled between them.

Mantra assets organization allow you to do this.

In "ComponentsLocations" property of mantraconfig.json project configuration file, you can set a number of different folders to organize all your components; for instance:

"ComponentsLocations": [
   "components/admin",
   "components/base",
   "components/mantrakit",
   "components/orquestation",
   "components/publicapi"]

As you can see in this example, there exists five differents folder for specific components according to their purposes:

• "components/admin": for admin components.

• "components/base": for components that expose specific functionality for final users.

• "components/mantrakit": a number of standard Mantra components downloaded from this site.

• "components/orchestration": for components in charge of orchestrating events raised in the system for implementing high level functionality.

• "components/publicapi": for components that are in charge of implementing all stuff regarding to a public REST API.

You can set the distribution of your components that best suits to them.

On the other hand, usually, a functionality for a given area of an application, needs administration and final user functionality, for instance.

In this case, Mantra development culture encourages you to develop two differents components: one for admin purposes and other for end user functionality.

As an example, given a component named "users" for managing all stuff related to users, we can have 3 differents components:

• "users-core": the main component the defines a data model and an API to exposes its base functionality and CRUD operations.

• "users-ui": the component that implements all views and blocks to show in the user interfaces.

• "users-admin": the component that includes all admin stuff related to users, including, maybe, some commands for any kind of maintenance tasks.

The way you split the functionality of your components and how they are organized as assets in the project is very important for its maintenability and the reusability of the components.