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
UseCase
is part of anApp
- an
App
is mounted in aProduct
- a
Product
is exposed via aTarget
- a
Target
is 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.