macss

Modular Architecture for Comprehensive Software Solutions

MACSS is a software architecture methodology designed for AI-assisted development. It defines a layered architecture with single-responsibility components and a monorepo structure that gives both the developer and the AI agent complete, unambiguous context over the entire system. The result: a developer with an AI copilot operates as a true full-stack team.

Principles

AI agents perform best when they can reason about a codebase with clear boundaries, predictable structure, and explicit contracts. MACSS provides exactly that:

Layer architecture

Every request flows through layers with a single responsibility. The architecture enforces separation: UI never touches the database, business logic never knows about HTTP, persistence never formats responses.

Sequence diagram showing the request flow: User → Interface → Controller → Service → API → UseCase → Repository → DB, and the response path back.
InterfacePresents information and captures user interactions. UI or CLI.
ControllerManages application state. Orchestrates calls between interface and services.
ServiceHTTP communication layer between client and server. Abstracts transport.
APIServer that exposes endpoints and routes requests to use cases.
UseCaseBusiness logic. Typed Input/Output, validate() + execute() lifecycle.
RepositoryData access. Executes SQL queries and commands.
DBPersistence. Managed as Database as Code — DDL scripts, no ORMs.
api

Server-side SDK. Implements the UseCase lifecycle, CQRS routing, OpenAPI generation, health and metrics.

modular_api →
app

Client-side SDKs. Transport-agnostic REST and GraphQL clients with the Result pattern, shipped inside modular_api. No raw HTTP in the presentation layer.

modular_api clients →

Monorepo structure

Every MACSS project is a single repository with a canonical layout. The AI agent — and the developer — find everything in a predictable location.

project/
├── code/
│   ├── db/    → SQL schemas, DDL scripts, repositories
│   ├── api/   → use cases, endpoints, server
│   ├── app/   → services, controllers, views
│   └── infra/ → CI, containers, environment config
├── docs/
│   ├── adr/          → architecture decision records
│   ├── architecture.md
│   └── roadmap.md
└── README.md

Within code/, business logic is organized as modules — vertical slices that group related use cases from the same domain:

code/api/modules/
├── clients/   → create, list, get, update, delete
├── billing/   → invoice, payment, refund
└── inventory/ → stock, transfer, adjustment

Each module has explicit boundaries and declared dependencies. When a module needs to scale independently, it can be extracted as a separate service without modifying its internal structure.

CLI

The macss CLI carries the delivery cycle: it opens the requisition, adds the contract, publishes both to a GitHub issue, runs the stage gates, and takes the delivery and its evidence to a pull request.

Routes are one of two kinds. A query reads and answers — check, list, doctor. A command changes something, and says what it would change before it does: every one takes --plan or --apply, and neither is the default.

PowerShell irm https://macss.dev/install.ps1 | iex

Installs to %LOCALAPPDATA%\macss\, adds macss and alias ma to PATH.

macss project create --path <dir> --lang <en|es> --apply

Scaffold a new project with code/{db,api,app,infra} and documentation templates.

macss requisition new <slug> --apply

Open a requisition: the Product Owner's form, its issue metadata, and the active pointer.

macss requisition publish --plan

Show what would reach GitHub — the exact gh line included — and change nothing.

macss dor check

Definition of Ready: the request, the contract, and a published issue.

macss delivery publish --apply

Push the branch and open the pull request from the delivery.

macss help

Every route this CLI accepts, listing what reads apart from what changes.

Ecosystem

Modular API framework — server side. Use cases, CQRS, OpenAPI, health and metrics out of the box.
macss CLI
The delivery cycle, end to end. Scaffolds the four-layer structure, carries requisition to pull request, and runs the stage gates.