Domain Model — Contexts and Layers#

Audience. Developers and AI agents changing a domain package, a module boundary, or a commerce flow. This doc is the map of Lesstruct’s DDD adoption: which bounded contexts exist, how they relate, and which layer owns what.

Companions: ubiquitous-language.md for the vocabulary, orders-bounded-context.md for the deep commerce example, and the repo-only PlantUML sources context-map.puml / class-diagram.puml (the docs site renders the Mermaid summary below instead).

How DDD is applied#

Lesstruct is modular by construction: a first-party feature is a Go module under modules/<name>/, and the module is the compile-time unit a context is deployed as. Most contexts are exactly one module (catalog, cart, orders, payments, media, users, auth, textgen); Content Publishing is one context split across cooperating modules (content, posttypes-basic, comments, seo, importers) because each carries its own lifecycle and schema. The model inside a domain package is ordinary Go — structs with behaviour, sentinel errors, and narrow interfaces — not a framework.

The layer grammar is fixed:

The domain Service is the application layer. There is deliberately no separate application/ package. A service method is one use case: it validates input, loads the aggregate through a port, enforces the invariant, writes through a port, and performs best-effort side effects. This keeps the module small and makes the transaction boundary explicit in the store implementation. Consumers that need more orchestration put it in an edition adapter, where cross-context wiring belongs.

Why these trade-offs#

• No domain events. Module boundaries are compile-time seams, and the authoritative writes are single-row conditional statements. Cross-context effects (stock release, email, plugin hooks) are inline and ordered around those writes, so the code shows the race semantics instead of hiding them behind a bus. See ConfirmPaid in orders-bounded-context.md.
• No generic repository. Each context declares only the methods its use cases need. A store can satisfy several ports structurally, but no shared Repository[T] abstraction exists to leak storage assumptions into the model.
• No ORM or identity map. Stores are hand-written SQL over database/sql; entities are loaded per call. Conditional updates (UPDATE … WHERE stock + ? >= 0, MarkPaid) are the concurrency primitive.
• Integer minor units, not floats. Money is stored as int64 in every table and on the wire. The orders context wraps it in the Money value object when a document must render an amount with its currency (Money). Catalog and cart carry bare integers because the platform adopts one currency at startup and attaches it at the presentation boundary; orders is where a stored order can outlive a currency change, so it carries the currency with every amount.
• Primitive request inputs. Service methods accept small request structs or primitives rather than command objects. Validation still belongs to the service, so the HTTP layer cannot bypass it.
• Known library coupling. A few domains import low-level libraries that implement the computation rather than an adapter: media (and profilepicture) use image codecs, and posttypes-basic parses TOML field schemas. These are computation libraries, not remote-system adapters; the plugin runtime handle lives in internal/plugin/loader, AI clients in modules/<name>/infrastructure/, and the payment gateway in modules/payments/midtrans — all outside the domain.

Bounded contexts#

internal/domain/apikey, content, dashboard, plugin, and role are the five contexts whose code still lives in the root module. Everything else is an extracted Go module. New first-party features go to modules/<name>/ (see project-context.md).

Context map#

flowchart LR
    subgraph Content Community
        CNT[Content Publishing]
        MED[Media Library]
        SEO[SEO / Aliases]
        IMP[Importers]
    end
    subgraph Commerce
        CAT[Catalog]
        CART[Cart]
        ORD[Orders]
        PAY[Payments]
        MID[[Midtrans]]
    end
    subgraph Identity
        USR[Users]
        AUTH[Auth]
        ROLE[Roles]
    end
    AI[AI Assist]
    K[(Kernel published language)]

    IMP --> CNT
    CNT --> SEO
    CNT --> MED
    CNT --> AI
    CAT --> CNT
    CART --> CAT
    ORD --> CART
    ORD --> CNT
    ORD --> CAT
    PAY --> ORD
    PAY --> MID
    AUTH --> USR
    USR --> ROLE
    CNT --> K
    MED --> K
    CAT --> K
    CART --> K
    ORD --> K
    PAY --> K
    USR --> K

Relationship patterns, in DDD terms:

The commerce chain is a Requires chain: cart requires catalog, orders requires cart, payments requires orders. Disabling an upstream module cascades its dependents off the registry, so a half-wired commerce binary cannot boot.

Aggregates and value objects#

Money#

orders.Money is the only currency-bearing value object:

1
2
3
4

type Money struct {
    Amount   int64  // minor units, never a float
    Currency string // ISO 4217-ish code adopted from [catalog] currency
}

• NewMoney(amount, currency) pairs the ledger integer with its code.
• Format() renders IDR 598,000 for zero-decimal currencies (IDR, JPY, KRW, VND) and USD 59.80 for the rest. Negative amounts render with a leading -.
• Persistence and wire shapes stay integers (subtotal, shippingMinor, unitPrice, …). Money exists so a render path cannot pair one order’s amount with another currency by accident.
• Tax is display-only. BuildInvoice computes Tax = Total × rate / 100 for the PDF breakdown; the order total remains the money truth and is never rewritten by an invoice read.

Domain services and ports#

A typical domain package declares its ports beside its model:

Best-effort side effects are explicit: _ = s.mail.Send…, _ = s.inventory.Release…. The authoritative write already happened, so the domain reports the original failure rather than a cleanup or delivery miss.

Testing the model#

• Every domain/ package carries a 100% statement-coverage bar: the root runs go test -cover ./internal/domain/..., and each extracted Go module runs go test -cover ./domain/... from its own directory. See module-development.md.
• Tests live in <package>_test and are table-driven (tt loop variable, name first, wantErr where errors return). They exercise public behaviour only.
• Mocks are generated with make mock (mockery + testify); narrow seams sometimes use hand-written recording stubs for clarity. Test-only seams (clock, entropy) are package variables swapped through export_test.go helpers and restored with t.Cleanup.