Architecture center · source revision pinned

Open Mercato Architecture: A Code-Evidenced System Atlas

Open Mercato is a modular, multi-tenant business-application foundation. A Next.js host assembles enabled modules around shared authentication, authorization, commands, data, queries, and events, then connects them to pluggable infrastructure and external systems. The atlas below follows those contracts without treating any mechanism as proof of deployment quality.

System map, not a security, performance, availability, or implementation certification.

Source snapshot:

ae856df1ecfc · ARCHITECTURE.md sections: 1, 2

How to read the whole system

Read downward from caller to application, cross-cutting services, enabled modules, infrastructure, and stores. Read sideways for extension and external-system boundaries. Each highlighted path names the scope it must preserve and the owner that still has to operate it.

Choose one flow through the same system layers

A selection changes the highlight and URL. Every layer and ordered trace remains available in the document.

Static semantic map; color indicates the selected trace.
01

Browser and API consumer

external system

02

Next.js application routes

application local

03

Auth, RBAC, CRUD, commands, data, queries, and events

oss core

04

Enabled business modules

oss core

05

Cache, queue, search, scheduler, encryption

infrastructure package

06

PostgreSQL, Redis, and Meilisearch

external system

07

Provider package or external system

provider addon

Request carries authenticated tenant and organization scope into services.Generated registries connect enabled modules to application routes and runtime services.Command and DataEngine writes may emit events and maintain read-side indexes.Persistent subscribers and workers move retryable work through the queue boundary.Adapters and webhooks cross into provider or external-system responsibility.

Request carries authenticated tenant and organization scope into services.

Generated registries connect enabled modules to application routes and runtime services.

Command and DataEngine writes may emit events and maintain read-side indexes.

Persistent subscribers and workers move retryable work through the queue boundary.

Adapters and webhooks cross into provider or external-system responsibility.

Scoped read

  1. An application route resolves an enabled module page.
  2. Authentication establishes tenant and organization context.
  3. QueryEngine reads the scoped denormalized model.
  4. The server renders semantic content for the response.
Read the detailed guide for this mechanism

Command and write

  1. The route checks access, parses input, and applies explicit scope.
  2. Mutation guards may block the operation before execution.
  3. CommandBus executes the registered mutation and records its audit context.
  4. DataEngine persists the record and schedules declared events or index work.
Read the detailed guide for this mechanism

Event and background work

  1. The module declares a typed event contract.
  2. The event bus dispatches matching in-memory handlers.
  3. Persistent subscribers cross the queue boundary for retryable work.
  4. The worker must be idempotent and observed through failure and retry.
Read the detailed guide for this mechanism

Cross-module extension

  1. The extending module chooses a stable cross-module surface instead of importing peer internals.
  2. A widget, interceptor, enricher, guard, command hook, event, or entity link carries the extension.
  3. Generation records the enabled contract in the runtime registry.
  4. The implementation still has to handle the peer module or optional surface being absent.
Read the detailed guide for this mechanism

External integration

  1. The implementation defines which system owns each identifier and state transition.
  2. A provider adapter or route verifies the external contract and credentials.
  3. Queues or schedules isolate retryable and recurring work.
  4. Acknowledgement, deduplication, reconciliation, and outage recovery remain implementation obligations.
Read the detailed guide for this mechanism

Mechanism, implication, limitation, owner

Mechanism, implication, limitation, owner
MechanismEditorial implicationLimitationDecision owner
Open Mercato is a modular, multi-tenant ERP and CRM foundation that teams self-host and extend.Treat it as an “oss-core” contract and confirm project-specific fit separately.The mechanism does not prove performance, security, availability, compliance, or production readiness for a particular deployment.Application architect
The documented system separates application routes, cross-cutting services, modules, pluggable infrastructure, and data stores.Treat it as an “documented-convention” contract and confirm project-specific fit separately.The mechanism does not prove performance, security, availability, compliance, or production readiness for a particular deployment.Application architect
Sources and method · 34 evidence records

Every fact, node, connector, and flow step has a stable ID, claim class, source locator, scope, limitation, and pinned revision. A local verifier checks every file and locator and ensures sections 1–33 are covered exactly once.

  • Open Mercato is a modular, multi-tenant ERP and CRM foundation that teams self-host and extend.

    ID
    section-01-product-foundation
    Class
    product-fact
    Scope
    oss-core
    Source
    ARCHITECTURE.md · ## 1. What is Open Mercato
  • The documented system separates application routes, cross-cutting services, modules, pluggable infrastructure, and data stores.

    ID
    section-02-system-layers
    Class
    product-fact
    Scope
    documented-convention
    Source
    ARCHITECTURE.md · ## 2. High-Level Architecture
  • Browser and API consumer

    ID
    node-browser
    Class
    editorial-interpretation
    Scope
    external-system
    Source
    ARCHITECTURE.md · ### System overview
  • Next.js application routes

    ID
    node-application
    Class
    product-fact
    Scope
    application-local
  • Auth, RBAC, CRUD, commands, data, queries, and events

    ID
    node-cross-cutting
    Class
    editorial-interpretation
    Scope
    oss-core
    Source
    ARCHITECTURE.md · ### Layers, top to bottom
  • Enabled business modules

    ID
    node-modules
    Class
    product-fact
    Scope
    oss-core
  • Cache, queue, search, scheduler, encryption

    ID
    node-infrastructure
    Class
    editorial-interpretation
    Scope
    infrastructure-package
    Source
    ARCHITECTURE.md · subgraph "Infrastructure (pluggable via DI)"
  • PostgreSQL, Redis, and Meilisearch

    ID
    node-data
    Class
    product-fact
    Scope
    external-system
    Source
    ARCHITECTURE.md · subgraph "Data"
  • Provider package or external system

    ID
    node-provider
    Class
    editorial-interpretation
    Scope
    provider-addon
    Source
    ARCHITECTURE.md · External integration provider
  • Request carries authenticated tenant and organization scope into services.

    ID
    edge-request-scope
    Class
    product-fact
    Scope
    oss-core
    Source
    packages/shared/src/lib/api/scoped.ts · export function withScopedPayload
  • Generated registries connect enabled modules to application routes and runtime services.

    ID
    edge-module-contract
    Class
    product-fact
    Scope
    oss-core
    Source
    packages/cli/src/lib/generators/module-registry.ts · modules.runtime.generated.ts
  • Command and DataEngine writes may emit events and maintain read-side indexes.

    ID
    edge-write-side-effects
    Class
    product-fact
    Scope
    oss-core
    Source
    packages/shared/src/lib/data/engine.ts · async emitOrmEntityEvent
  • Persistent subscribers and workers move retryable work through the queue boundary.

    ID
    edge-background
    Class
    product-fact
    Scope
    infrastructure-package
    Source
    packages/events/src/bus.ts · persistentSubscribers
  • Adapters and webhooks cross into provider or external-system responsibility.

    ID
    edge-external
    Class
    editorial-interpretation
    Scope
    provider-addon
    Source
    packages/webhooks/src/modules/webhooks/lib/adapter-registry.ts · export interface WebhookEndpointAdapter
  • An application route resolves an enabled module page.

    ID
    flow-read-route
    Class
    product-fact
    Scope
    oss-core
  • Authentication establishes tenant and organization context.

    ID
    flow-read-scope
    Class
    product-fact
    Scope
    oss-core
    Source
    packages/shared/src/lib/api/scoped.ts · export type ScopedContext
  • QueryEngine reads the scoped denormalized model.

    ID
    flow-read-query
    Class
    product-fact
    Scope
    oss-core
    Source
    packages/core/src/modules/query_index/lib/engine.ts · export class HybridQueryEngine
  • The server renders semantic content for the response.

    ID
    flow-read-render
    Class
    product-fact
    Scope
    oss-core
  • The route checks access, parses input, and applies explicit scope.

    ID
    flow-write-validate
    Class
    product-fact
    Scope
    oss-core
    Source
    packages/shared/src/lib/crud/factory.ts · export function makeCrudRoute
  • Mutation guards may block the operation before execution.

    ID
    flow-write-guard
    Class
    product-fact
    Scope
    oss-core
    Source
    packages/shared/src/lib/crud/factory.ts · runMutationGuards
  • CommandBus executes the registered mutation and records its audit context.

    ID
    flow-write-command
    Class
    product-fact
    Scope
    oss-core
    Source
    packages/shared/src/lib/commands/command-bus.ts · export class CommandBus
  • DataEngine persists the record and schedules declared events or index work.

    ID
    flow-write-effects
    Class
    product-fact
    Scope
    oss-core
    Source
    packages/shared/src/lib/data/engine.ts · async emitOrmEntityEvent
  • The module declares a typed event contract.

    ID
    flow-event-declare
    Class
    product-fact
    Scope
    oss-core
    Source
    packages/shared/src/modules/events/factory.ts · export function createModuleEvents
  • The event bus dispatches matching in-memory handlers.

    ID
    flow-event-emit
    Class
    product-fact
    Scope
    oss-core
    Source
    packages/events/src/bus.ts · export function createEventBus
  • Persistent subscribers cross the queue boundary for retryable work.

    ID
    flow-event-persist
    Class
    product-fact
    Scope
    oss-core
    Source
    packages/events/src/bus.ts · persistentSubscribers
  • The worker must be idempotent and observed through failure and retry.

    ID
    flow-event-operate
    Class
    documented-convention
    Scope
    oss-core
    Source
    ARCHITECTURE.md · ## 19. Queue and Background Jobs
  • The extending module chooses a stable cross-module surface instead of importing peer internals.

    ID
    flow-extension-boundary
    Class
    documented-convention
    Scope
    oss-core
    Source
    ARCHITECTURE.md · ### Extensibility boundary: inject vs compose
  • A widget, interceptor, enricher, guard, command hook, event, or entity link carries the extension.

    ID
    flow-extension-surface
    Class
    product-fact
    Scope
    oss-core
  • Generation records the enabled contract in the runtime registry.

    ID
    flow-extension-registry
    Class
    product-fact
    Scope
    oss-core
    Source
    packages/cli/src/lib/generators/module-registry.ts · bootstrap-registrations.generated.ts
  • The implementation still has to handle the peer module or optional surface being absent.

    ID
    flow-extension-absence
    Class
    documented-convention
    Scope
    oss-core
    Source
    ARCHITECTURE.md · A module must work enabled or disabled.
  • The implementation defines which system owns each identifier and state transition.

    ID
    flow-integration-authority
    Class
    documented-convention
    Scope
    provider-addon
    Source
    ARCHITECTURE.md · ### Webhooks
  • A provider adapter or route verifies the external contract and credentials.

    ID
    flow-integration-adapter
    Class
    product-fact
    Scope
    provider-addon
    Source
    packages/webhooks/src/modules/webhooks/lib/adapter-registry.ts · export interface WebhookEndpointAdapter
  • Queues or schedules isolate retryable and recurring work.

    ID
    flow-integration-async
    Class
    product-fact
    Scope
    provider-addon
  • Acknowledgement, deduplication, reconciliation, and outage recovery remain implementation obligations.

    ID
    flow-integration-reconcile
    Class
    documented-convention
    Scope
    provider-addon
    Source
    ARCHITECTURE.md · Workers and subscribers MUST be idempotent.