@opengroundplan/core 0.1.1

package/catalog/architectures/event-driven.yaml

@@ -0,0 +1,59 @@
+id: event-driven
+name: Event-Driven Architecture
+family: system
+oneLine: >-
+  Producers emit events to a channel and consumers react independently with no producer knowledge
+  of them — trading synchronous certainty for decoupling and eventual consistency.
+
+bestFor:
+  - Notification fan-out and telemetry/IoT ingestion
+  - Decoupling teams that deploy independently
+  - Audit and analytics tap-off without touching the write path
+  - Hard latency plus fault-tolerance requirements — Richards scores it 5 on both
+
+avoidWhen:
+  - Single deployable, single team
+  - You need a synchronous answer to the caller
+  - You have no observability plan; retrofitting tracing into a decoupled system is far harder than building it in
+  - You would reach for a durable log when a fanout exchange would have done
+
+complexity: high
+teamSize: { min: 5, max: 1000 }
+
+# Richards & Ford, Architecture Styles Worksheet V2.0 — "event-driven" column, verbatim.
+# The row that inverts the microservices story: responsiveness 5 vs microservices' 2.
+# cost inverted from the $ row: $$$ = 3.
+scores:
+  maintainability: 3
+  testability: 2
+  deployability: 3
+  simplicity: 2
+  scalability: 4
+  elasticity: 3
+  responsiveness: 5
+  fault-tolerance: 5
+  evolvability: 5
+  abstraction: 4
+  interoperability: 3
+  cost: 3
+
+stackFit:
+  typescript: good        # NestJS transports, KafkaJS, amqplib
+  python: good            # FastStream; Celery is a task queue, not an event broker
+  dotnet: excellent       # MassTransit, NServiceBus, Rebus, Wolverine, Service Bus/Event Hubs
+  node: good
+  go: good
+  rust: workable
+  java: excellent         # Kafka's home ecosystem
+  polyglot: excellent     # Dapr pub/sub abstracts the broker behind a sidecar
+
+keyTradeoff: >-
+  You trade a traceable call stack for decoupling; observability must be designed in from day one.
+
+overlay: event-driven
+
+sources:
+  - https://www.developertoarchitect.com/downloads/architecture-styles-worksheet.pdf
+  - https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
+  - https://martinfowler.com/articles/201701-event-driven.html
+  - https://learn.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber

package/catalog/architectures/feature-sliced-design.yaml

@@ -0,0 +1,61 @@
+id: feature-sliced-design
+name: Feature-Sliced Design
+family: frontend
+oneLine: >-
+  An architectural methodology for scaffolding front-end applications — layers (App, Pages, Widgets,
+  Features, Entities, Shared) sliced by business domain and segmented by technical nature, with
+  imports allowed only downward.
+
+bestFor:
+  - Front-end applications with meaningful business-domain decomposition
+  - Codebases already hitting onboarding difficulty or trouble shipping features because of structural complexity
+  - Teams that want enforced one-way coupling between layers rather than convention alone
+  - Projects that want to keep Atomic Design's atoms and molecules, which FSD nests inside shared/ui
+
+avoidWhen:
+  - You are building a library — FSD's docs state it targets applications, not libraries
+  - The current architecture works; the docs say plainly it may not be worth changing
+  - The app is small — the official tutorial itself avoids excessive decomposition at that size
+  - You were counting on the Processes layer, which is deprecated
+
+complexity: medium
+teamSize: { min: 2, max: 60 }   # engine input — feature-sliced.design publishes no team-size threshold
+
+# derived, not from Richards — frontend methodologies are not in the worksheet.
+# Calibrated against Richards' scale. This is a code-organization methodology, so the
+# runtime rows (scalability, elasticity, fault-tolerance) are inherited from the host app,
+# not conferred by the style; they are rated neutral rather than left out.
+scores:
+  maintainability: 4
+  testability: 4
+  deployability: 2   # organizes one deployable; confers no deploy independence
+  simplicity: 2      # substantial upfront ceremony, conceded by the docs for small apps
+  scalability: 1
+  elasticity: 1
+  responsiveness: 3
+  fault-tolerance: 1
+  evolvability: 4
+  abstraction: 4     # the layer rule is an explicit isolation contract
+  interoperability: 2
+  cost: 5
+
+stackFit:
+  typescript: excellent
+  python: n/a
+  dotnet: n/a
+  node: excellent
+  go: n/a
+  rust: n/a
+  java: n/a
+  polyglot: n/a
+
+keyTradeoff: >-
+  You buy enforced, greppable module boundaries and predictable coupling at the cost of substantial
+  upfront ceremony that the docs themselves concede is excessive for small apps.
+
+overlay: feature-sliced-design
+
+sources:
+  - https://feature-sliced.design/docs/get-started/overview
+  - https://feature-sliced.design/docs/reference/layers
+  - https://feature-sliced.design/docs/reference/slices-segments

package/catalog/architectures/hexagonal.yaml

@@ -0,0 +1,60 @@
+id: hexagonal
+name: Hexagonal (Ports and Adapters)
+family: application
+oneLine: >-
+  Allow an application to equally be driven by users, programs, automated tests, or batch scripts,
+  and to be developed and tested in isolation from its eventual runtime devices and databases.
+
+bestFor:
+  - Applications that must be driven by multiple entry types — users, other programs, automated tests, batch scripts
+  - Testing the core without the real runtime devices or databases
+  - Swapping technology behind a protocol; any device adhering to a port's protocol can be plugged in
+  - Untangling business logic from I/O, which Cockburn names as the root problem the pattern exists to solve
+
+avoidWhen:
+  - There is no entanglement to remove — the stated intent is scoped to that problem and offers no case beyond it
+  - The app is small enough that an adapter per external technology is pure overhead
+  - You want prescribed internal structure for the business logic; that is Onion's addition, not this one
+  - Your team would design ports around the tool's API rather than the application's needs, which inverts the pattern
+
+complexity: medium
+teamSize: { min: 2, max: 100 }   # engine input — no primary source publishes a team size for this style
+
+# derived, not from Richards — application-level styles are not columns in the worksheet.
+# Same calibration convention as clean.yaml: runtime rows stay at monolith values, cost stays $ (=5).
+# simplicity is 3 rather than clean's 2 because this prescribes two concentric zones, not four circles.
+# interoperability is 4 because equal support for many driving adapters is the explicit stated intent.
+scores:
+  maintainability: 4
+  testability: 5
+  deployability: 2
+  simplicity: 3
+  scalability: 1
+  elasticity: 1
+  responsiveness: 3
+  fault-tolerance: 1
+  evolvability: 4
+  abstraction: 5
+  interoperability: 4
+  cost: 5
+
+stackFit:
+  typescript: excellent
+  python: good        # Protocol classes work; ports are enforced by convention, not the compiler
+  dotnet: excellent
+  node: good
+  go: excellent       # small implicit interfaces are almost exactly what a port is
+  rust: excellent     # traits
+  java: excellent
+  polyglot: awkward
+
+keyTradeoff: >-
+  Total isolation of the core from delivery and infrastructure, paid for with an adapter per external
+  technology and an interface layer the application must own and maintain.
+
+overlay: hexagonal
+
+sources:
+  - https://alistair.cockburn.us/hexagonal-architecture/
+  - https://herbertograca.com/2017/09/14/ports-adapters-architecture/
+  - https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/

package/catalog/architectures/lakehouse.yaml

@@ -0,0 +1,63 @@
+id: lakehouse
+name: Lakehouse
+family: data
+oneLine: >-
+  A data management system based on low-cost, directly-accessible storage that also provides
+  traditional analytical DBMS features — ACID transactions, data versioning, auditing, indexing,
+  caching, and query optimization — via a transactional metadata layer over an object store.
+
+bestFor:
+  - Organizations already holding vast amounts of data in a data lake who want to avoid maintaining a second copy
+  - ML and data science needing direct large-scale reads in open formats rather than ODBC/JDBC extraction
+  - Unstructured and semi-structured data (video, audio, text) that warehouses could not store or query at all
+  - Cloud environments with separated compute and storage — an especially good fit, e.g. a GPU cluster reading the same storage
+  - Governance and regulatory cases where open formats mean direct access without blocking on a vendor
+
+avoidWhen:
+  - You need strict data independence — the storage format becomes part of the system's public API
+  - You would rather add a parallel serving layer over a warehouse; the authors argue that is more expensive to run, harder to manage, and likely less performant
+  - You intend to delete the lake and put everything in a warehouse — the paper calls this a straw-man with limited adoption
+  - Your ML stack uses APIs that do not push query semantics into the storage system, since you lose the optimization path
+  - You need settled metadata internals — Iceberg v4 is under active development and not formally adopted
+
+complexity: high
+teamSize: { min: 3, max: 200 }   # engine input — the CIDR paper is a systems argument, not an adoption guide
+
+# derived, not from Richards — data platform patterns are not in the worksheet.
+# Calibrated against Richards' scale. cost 4 is the paper's central claim: object storage plus open
+# formats undercuts the two-tier lake-plus-warehouse total cost of ownership.
+scores:
+  maintainability: 3
+  testability: 3
+  deployability: 3
+  simplicity: 2
+  scalability: 5
+  elasticity: 5   # compute and storage separate, so compute scales independently of the data
+  responsiveness: 3
+  fault-tolerance: 4
+  evolvability: 4
+  abstraction: 2  # deliberately low — direct access gives up some data independence
+  interoperability: 5  # open formats readable by many engines; UniForm bridges Delta/Iceberg/Hudi
+  cost: 4
+
+stackFit:
+  typescript: awkward
+  python: excellent
+  dotnet: workable
+  node: awkward
+  go: workable    # Iceberg/Delta client libraries exist
+  rust: good      # first-class Delta and Iceberg client implementations
+  java: excellent
+  polyglot: excellent
+
+keyTradeoff: >-
+  Exposing an open, directly-readable storage format buys low cost, no lock-in, and first-class ML
+  access, but it permanently constrains the engine's freedom to optimize because the format is now a
+  public API.
+
+sources:
+  - https://www.cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf
+  - https://github.com/apache/iceberg/blob/main/format/spec.md
+  - https://delta.io/
+
+overlay: lakehouse

package/catalog/architectures/layered.yaml

@@ -0,0 +1,60 @@
+id: layered
+name: Layered (N-Tier)
+family: application
+oneLine: >-
+  Technically partitioned horizontal layers — presentation, business, persistence, database —
+  where each layer is a closed abstraction that requests only pass downward through.
+
+bestFor:
+  - Small applications where familiarity outranks every other characteristic
+  - Teams with no prior architecture convention, as a starting point that everyone already knows
+  - Short-lived or throwaway systems where evolvability genuinely does not matter
+  - Codebases whose change pattern really is technical (swap the ORM, swap the UI) rather than by feature
+
+avoidWhen:
+  - Any greenfield product — modular-monolith dominates layered on every scored row at identical cost
+  - Change requests arrive by business feature, forcing every change to touch all layers ("architecture sinkhole")
+  - Independent deployability or fault isolation is needed at all
+  - The domain is expected to grow; layered scores 1 on evolvability
+
+complexity: low
+teamSize: { min: 1, max: 12 }
+
+# Richards & Ford, Architecture Styles Worksheet V2.0 — "layered" column, verbatim.
+# cost inverted from the $ row: $=5 (cheap) … $$$$$=1 (expensive), so higher is always better.
+scores:
+  maintainability: 1
+  testability: 2
+  deployability: 1
+  simplicity: 5
+  scalability: 1
+  elasticity: 1
+  responsiveness: 3
+  fault-tolerance: 1
+  evolvability: 1
+  abstraction: 1
+  interoperability: 1
+  cost: 5
+
+stackFit:
+  typescript: good
+  python: good
+  dotnet: good
+  node: good
+  go: workable
+  rust: workable
+  java: good
+  polyglot: awkward
+
+keyTradeoff: >-
+  You buy maximum familiarity and the lowest possible starting cost with technical partitioning
+  that makes every feature change a multi-layer edit — and Richards' own matrix shows modular
+  monolith beats it on maintainability and deployability for the same money.
+
+overlay: layered
+
+sources:
+  - https://www.developertoarchitect.com/downloads/architecture-styles-worksheet.pdf
+  - https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/n-tier
+  - https://herbertograca.com/2017/08/03/layered-architecture/
+  - https://martinfowler.com/bliki/PresentationDomainDataLayering.html

package/catalog/architectures/llm-workflow.yaml

@@ -0,0 +1,59 @@
+id: llm-workflow
+name: LLM Workflow (Predefined Code Paths)
+family: ai
+oneLine: >-
+  Systems where LLMs and tools are orchestrated through predefined code paths — prompt chaining,
+  routing, parallelization, orchestrator-workers, evaluator-optimizer.
+
+bestFor:
+  - Tasks that can be easily and cleanly decomposed into fixed subtasks
+  - Complex tasks with distinct categories that are better handled separately (routing)
+  - Subtasks that can be parallelized for speed, or where multiple perspectives raise confidence
+  - Cases with clear evaluation criteria where iterative refinement provides measurable value
+  - Anywhere predictability and consistency for well-defined tasks outrank flexibility
+
+avoidWhen:
+  - The number of steps is unpredictable — that is the boundary where an agentic loop starts
+  - A single well-optimized prompt suffices; add multi-step systems only when simpler solutions fall short
+  - You cannot predict the needed subtasks at design time
+  - Flexibility and model-driven decision-making at scale is the actual requirement
+
+complexity: low
+teamSize: { min: 1, max: 20 }   # engine input — no primary source publishes a team size for this pattern
+
+# derived, not from Richards — AI application patterns are not in the worksheet.
+# Calibrated against Richards' scale. testability is high relative to agentic styles precisely
+# because the control flow is fixed in code and each step is independently assertable.
+scores:
+  maintainability: 4
+  testability: 4
+  deployability: 4
+  simplicity: 4
+  scalability: 4
+  elasticity: 4
+  responsiveness: 3   # chaining explicitly trades latency for accuracy; each step is a serial round trip
+  fault-tolerance: 3
+  evolvability: 3
+  abstraction: 3
+  interoperability: 3
+  cost: 4
+
+stackFit:
+  typescript: excellent
+  python: excellent
+  dotnet: good
+  node: excellent
+  go: good
+  rust: workable      # no first-party SDK; HTTP API only
+  java: good
+  polyglot: good
+
+keyTradeoff: >-
+  You buy determinism and debuggability by fixing the control flow in code, which caps the system's
+  ability to handle inputs the designer did not anticipate.
+
+sources:
+  - https://www.anthropic.com/engineering/building-effective-agents
+  - https://platform.claude.com/docs/en/agents-and-tools/tool-use/how-tool-use-works
+
+overlay: llm-workflow

package/catalog/architectures/medallion.yaml

@@ -0,0 +1,60 @@
+id: medallion
+name: Medallion (Bronze / Silver / Gold)
+family: data
+oneLine: >-
+  A data design pattern for logically organizing data in a lakehouse, incrementally and progressively
+  improving structure and quality as data flows through bronze (raw), silver (validated), and gold
+  (enriched) layers.
+
+bestFor:
+  - Lakehouse pipelines needing incremental quality improvement with auditability and replay from raw
+  - CDC and historical archival of source systems, which is bronze's stated focus
+  - Mixed batch and streaming ingestion from object storage, event logs, or federated systems
+  - Serving distinct audiences per layer — engineers and audit at bronze, analysts and scientists at silver, BI at gold
+
+avoidWhen:
+  - You would write to silver directly from ingestion — explicitly not recommended, since schema changes and corrupt records will break it
+  - You expect the pattern to be mandatory; Databricks calls it a recommended best practice but not a requirement
+  - You expect it to replace dimensional modeling — it does not; star schemas and data marts live *in* the gold layer
+  - You need large historical scans from gold; that data is typically accessed at silver and not materialized in gold
+
+complexity: medium
+teamSize: { min: 2, max: 100 }   # engine input — Databricks docs imply role specialization but state no headcount
+
+# derived, not from Richards — data platform patterns are not in the worksheet.
+# Calibrated against Richards' scale. cost 3 reflects the defining trade: the same data is stored
+# and processed three times.
+scores:
+  maintainability: 4
+  testability: 4   # per-layer quality gates are assertable checkpoints
+  deployability: 3
+  simplicity: 3
+  scalability: 4
+  elasticity: 4
+  responsiveness: 2   # progressive refinement is inherently multi-hop latency
+  fault-tolerance: 4  # bronze preserves raw fidelity, so any layer can be rebuilt
+  evolvability: 4
+  abstraction: 4
+  interoperability: 3
+  cost: 3
+
+stackFit:
+  typescript: awkward
+  python: excellent   # the documented API surface is PySpark plus SQL
+  dotnet: workable
+  node: awkward
+  go: awkward
+  rust: workable
+  java: good          # Spark/Scala/Java is first-class
+  polyglot: good      # SQL is the common denominator across layers
+
+keyTradeoff: >-
+  You gain replayability, auditability, and progressive quality gates in exchange for storing and
+  processing the same data multiple times across three layers.
+
+overlay: medallion
+
+sources:
+  - https://www.databricks.com/glossary/medallion-architecture
+  - https://docs.databricks.com/aws/en/lakehouse/medallion
+  - https://learn.microsoft.com/en-us/azure/databricks/lakehouse/medallion

package/catalog/architectures/micro-frontends.yaml

@@ -0,0 +1,60 @@
+id: micro-frontends
+name: Micro-Frontends
+family: system
+oneLine: >-
+  Independently deliverable frontend applications, each owned by a separate team, composed at build
+  time or runtime into a single user-facing product.
+
+bestFor:
+  - Four or more autonomous teams already owning vertical slices and blocked on each other's release trains
+  - Incremental strangler-fig migration off a legacy frontend
+  - Large surfaces with genuinely unrelated page collections
+  - Multi-tenant or white-label shells where third parties plug in their own UI
+
+avoidWhen:
+  - Fewer than about three frontend teams — a monorepo with enforced boundaries gives most of the benefit at a fraction of the cost
+  - Highly interdependent pages where users constantly cross boundaries; every crossing is a hard navigation or a shared-state negotiation
+  - No mature versioned design system and no platform team to enforce it
+  - You have not yet tried Next.js multi-zones, which for most teams reaching for this is the right answer
+  - You would mix competing frameworks on one page — ThoughtWorks holds "micro frontend anarchy" specifically for this
+
+complexity: high
+teamSize: { min: 25, max: 1000 }
+
+# derived, not from Richards — no micro-frontends column exists in the worksheet.
+# Calibrated against Richards' scale; responsiveness is low because Jackson names payload size
+# as the first cost — you spend your users' load time to buy your org chart's independence.
+scores:
+  maintainability: 3
+  testability: 2
+  deployability: 5
+  simplicity: 1
+  scalability: 3
+  elasticity: 3
+  responsiveness: 2
+  fault-tolerance: 3
+  evolvability: 4
+  abstraction: 2
+  interoperability: 3
+  cost: 2
+
+stackFit:
+  typescript: excellent   # Module Federation 2.0 fixed types-across-remotes; Rspack is the perf default
+  python: n/a             # not applicable — Python sits behind the BFF
+  dotnet: awkward         # Blazor has no MF equivalent; composition is YARP/RCL or iframes
+  node: excellent
+  go: n/a
+  rust: n/a
+  java: awkward
+  polyglot: awkward       # mixing frameworks on one page is the documented anti-pattern
+
+keyTradeoff: >-
+  You trade runtime performance and UX coherence for team deployment autonomy — payload size is the
+  first cost, and page performance relates directly to user engagement and conversion.
+
+overlay: micro-frontends
+
+sources:
+  - https://martinfowler.com/articles/micro-frontends.html
+  - https://www.thoughtworks.com/radar/techniques/micro-frontend-anarchy
+  - https://nextjs.org/docs/app/guides/multi-zones

package/catalog/architectures/microservices.yaml

@@ -0,0 +1,62 @@
+id: microservices
+name: Microservices
+family: system
+oneLine: >-
+  Two or more independently deployable, loosely coupled services, each owning a bounded context
+  and its own datastore, aligned to a team.
+
+bestFor:
+  - Genuinely asymmetric scaling profiles across subsystems
+  - Many teams needing deploy autonomy — the deploy queue, not the codebase, is the real driver
+  - Real polyglot need (a Python inference service beside a .NET transactional service)
+  - Fault isolation and characteristic-based segregation for security or compliance zones
+
+avoidWhen:
+  # Fowler's four prerequisites — all four, or don't start.
+  - Rapid provisioning, business-and-technical monitoring, rapid deployment, or a real DevOps culture is missing
+  - Domain boundaries are unproven — microservices demand stable bounded contexts that are hard to refactor later
+  - Services would be chatty; Azure names A-to-B-to-C latency chains as the coupling symptom
+  - The team lacks distributed-systems experience
+  - Fewer than ~8 engineers — operational surface exceeds capacity regardless of the scoring
+
+complexity: very-high
+teamSize: { min: 25, max: 5000 }
+
+# Richards & Ford, Architecture Styles Worksheet V2.0 — "microservices" column, verbatim.
+# Note the non-obvious rows: simplicity 1, abstraction 1, responsiveness 2. It is not a general win.
+# cost inverted from the $ row: $$$$$ = 1.
+scores:
+  maintainability: 5
+  testability: 5
+  deployability: 5
+  simplicity: 1
+  scalability: 5
+  elasticity: 4
+  responsiveness: 2
+  fault-tolerance: 5
+  evolvability: 5
+  abstraction: 1
+  interoperability: 3
+  cost: 1
+
+stackFit:
+  typescript: good        # NestJS microservices transports, monorepo mode
+  python: good            # FastAPI + FastStream
+  dotnet: excellent       # Aspire for dev-time orchestration, Dapr for building blocks
+  node: good
+  go: excellent
+  rust: workable
+  java: excellent
+  polyglot: excellent     # the one style where polyglot is a feature, not a tax
+
+keyTradeoff: >-
+  You buy team deploy autonomy with distributed-systems complexity and the permanent loss of ACID
+  across boundaries — you adopt BASE whether you planned to or not.
+
+overlay: microservices
+
+sources:
+  - https://www.developertoarchitect.com/downloads/architecture-styles-worksheet.pdf
+  - https://martinfowler.com/bliki/MicroservicePremium.html
+  - https://martinfowler.com/bliki/MicroservicePrerequisites.html
+  - https://www.twilio.com/en-us/blog/developers/best-practices/goodbye-microservices

package/catalog/architectures/modular-monolith.yaml

@@ -0,0 +1,62 @@
+id: modular-monolith
+name: Modular Monolith
+family: application
+oneLine: >-
+  A single deployable unit whose internals are partitioned into enforced, business-capability-aligned
+  modules — modularity as a compile-time and lint-time property rather than a network property.
+
+bestFor:
+  - Greenfield products where domain boundaries are still being discovered (Fowler, MonolithFirst)
+  - Teams where a single deploy pipeline is not yet a coordination bottleneck
+  - Heavy intra-domain data flow, avoiding network hops between modules designed to work together
+  - Cost-sensitive systems — no API gateway, load balancer, or service discovery spend
+  - Any project that may later need to extract services; domain partitioning preserves the extraction path
+
+avoidWhen:
+  - Modules have genuinely divergent scaling profiles (one CPU-bound at 100x the volume of another)
+  - You need hard multi-tenant or compliance isolation that a process boundary gives and a module boundary does not
+  - The org is already large enough that many teams contend for one pipeline
+  - You cannot or will not enforce boundaries in CI — without a failing linter this degrades into a big ball of mud
+
+complexity: low
+teamSize: { min: 1, max: 30 }
+
+# Richards & Ford, Architecture Styles Worksheet V2.0 — "modular monolith" column, verbatim.
+# 2nd-edition addition; the 1st edition lacked this style.
+# cost inverted from the $ row: $=5 (cheap) … $$$$$=1 (expensive), so higher is always better.
+scores:
+  maintainability: 2
+  testability: 2
+  deployability: 2
+  simplicity: 5
+  scalability: 1
+  elasticity: 1
+  responsiveness: 3
+  fault-tolerance: 1
+  evolvability: 1
+  abstraction: 1
+  interoperability: 1
+  cost: 5
+
+stackFit:
+  # Rated on availability of build-failing boundary enforcement, which is the load-bearing tool here.
+  typescript: excellent   # Nx @nx/enforce-module-boundaries, tags + depConstraints
+  python: good            # import-linter layers/independence contracts
+  dotnet: excellent       # NetArchTest / ArchUnitNET
+  node: good
+  go: good                # internal/ is compiler-enforced
+  rust: good              # crate boundaries + workspace members
+  java: excellent         # Spring Modulith 2.1
+  polyglot: awkward
+
+keyTradeoff: >-
+  You trade independent deployability for the ability to refactor boundaries cheaply; get that
+  backwards and you pay the microservice premium to protect boundaries you never validated.
+
+overlay: modular-monolith
+
+sources:
+  - https://www.developertoarchitect.com/downloads/architecture-styles-worksheet.pdf
+  - https://martinfowler.com/bliki/MonolithFirst.html
+  - https://www.thoughtworks.com/insights/blog/microservices/modular-monolith-better-way-build-software
+  - https://signalvnoise.com/svn3/the-majestic-monolith/

package/catalog/architectures/monolith.yaml

@@ -0,0 +1,61 @@
+id: monolith
+name: Monolith (Single Deployable)
+family: system
+oneLine: >-
+  One deployable unit, one runtime, one database — the system-topology choice to keep every
+  component in a single process boundary and a single release train.
+
+bestFor:
+  - Pre-PMF products where the cheapest architecture to change beats the most scalable one
+  - Teams of one to five where a shared pipeline is not yet a coordination cost
+  - Systems whose characteristics are uniform — no subsystem needs materially different scale or availability
+  - Budgets that cannot absorb a broker, a mesh, a tracing backend, and per-service pipelines
+
+avoidWhen:
+  - Two or more teams are blocked on the same pipeline
+  - One measured component needs an order of magnitude more capacity than the rest
+  - Regulatory scope must be provably bounded to a subset of the code
+  - One component's failure must not stop the others serving
+
+complexity: low
+teamSize: { min: 1, max: 25 }
+
+# derived, not from Richards — no plain "monolith" column exists in the worksheet.
+# Anchored between Richards' layered and modular-monolith columns, which are identical on every
+# row except maintainability and deployability; this entry takes the modular values because a
+# single deployable with no internal partitioning discipline is not something to scaffold.
+scores:
+  maintainability: 2
+  testability: 2
+  deployability: 2
+  simplicity: 5
+  scalability: 1
+  elasticity: 1
+  responsiveness: 3
+  fault-tolerance: 1
+  evolvability: 1
+  abstraction: 1
+  interoperability: 1
+  cost: 5
+
+stackFit:
+  typescript: excellent
+  python: excellent
+  dotnet: excellent
+  node: excellent
+  go: excellent
+  rust: good
+  java: excellent
+  polyglot: n/a   # a single deployable is single-runtime by definition
+
+overlay: monolith
+
+keyTradeoff: >-
+  You give up independent deployability and fault isolation to eliminate every distributed-systems
+  failure mode at once — which is the correct trade until the deploy queue, not the code, becomes
+  the constraint.
+
+sources:
+  - https://martinfowler.com/bliki/MonolithFirst.html
+  - https://martinfowler.com/bliki/MicroservicePremium.html
+  - https://signalvnoise.com/svn3/the-majestic-monolith/