Architecture
libmodulor follows a 4-layer architecture with UseCase, App, Product, and Target. It structures business logic efficiently, keeping apps modular and scalable.
libmodulor defines a 4-layer architecture composed of : UseCase, App, Product, Target.
Semantically,
- a
UseCaseis part of anApp - an
Appis mounted in aProduct - a
Productis exposed via aTarget - a
Targetis installed/deployed somewhere
UseCase
A use case is a piece of business functionality. It takes an input, processes it through lifecycle methods (client and/or server), and gives an output.
Inspired by UML's Use case diagram and Event-driven architecture, schematically, it could be defined as follows :
Examples : SignIn, CreatePost, TransferAccount, InviteContacts...
Note how it always starts with a verb.
Concretely, it's a file named *UCD.ts containing the definition of the use case (io, lifecycle, policies, etc.).
App
An app is a logical group of use cases. It's like a "module" (whatever that means), inspired by Domain-driven design (DDD) bounded contexts.
Examples : Auth, Accounting, CMS...
Concretely, it's a folder containing metadata files (i18n.ts, manifest.ts...) and a ucds folder which contains the use case definitions.
Product
A product is a logical group of apps that are assembled together. It's simply what end users know and use.
Examples : GitHub, Facebook, LinkedIn, Airbnb...
Concretely, it's a folder containing i18n.ts, manifest.(js|ts) and the elements corresponding to the desired targets. For example, it will contain the screens of a mobile app or the pages of a website.
Target
A target defines how a product is "exposed" to the end user. It's a combination of platform and runtime.
Examples : web-react, web-angular, server-node, cli-node, cli-stricli...
Note that it's the only place where the "infrastructure" choices are applied. Targets can be generic and reusable across products.