Architecture

libmodulor defines a 4-layer architecture composed of : UseCase, App, Product, Target.

Semantically,

• a UseCase is part of an App
• an App is mounted in a Product
• a Product is exposed via a Target
• 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 :

$$O = clientMain(serverMain(I))$$

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.