None of the frameworks below are replaced wholesale by DNA. DNA is a textual description language tuned for code generation; each of these frameworks optimizes for something else — diagram-driven communication, workshop discovery, enterprise governance. The comparisons here are meant to help you carry vocabulary across, not to argue you should drop your existing practice.
Domain-Driven Design
Of all the frameworks here, DDD (Eric Evans, 2003) is closest in spirit. Both treat the business domain as the source of truth and code as a downstream concern. DNA is the same vocabulary expressed declaratively as JSON; DDD is the methodology + vocabulary expressed in narrative and code.
Concept mapping
| DDD | DNA | Notes |
|---|---|---|
| Bounded Context | Domain (dot-separated hierarchy) | 1:1. Bounded contexts draw model boundaries; Domain nodes do the same. |
| Ubiquitous Language | The Resource / Action / Operation / Role names you author | Every primitive name is the team's vocabulary; schemas enforce naming patterns, not semantics. |
| Entity | Resource with attributes (identity-bearing) | DNA doesn't formally distinguish Entities from Value Objects in v1 — usage matters, not declaration. |
| Aggregate Root | A Resource referenced by name from Operation.resource | The Resource an Operation acts on is the aggregate root for that change. |
| Application Service | Process (orchestrating multiple Operations) | DDD's app services orchestrate work across aggregates — that's a Process in DNA. |
| Domain Event | Operation.changes (state mutation) + Trigger.after (downstream reaction) | DNA currently has no first-class event primitive; the state-change side lives in Operation.changes, downstream reactions via Trigger.after. |
| Specification pattern | Rule (type: condition) | Condition Rules are named, reusable predicates, composable via Step.conditions. |
| Repository / Factory | Not modeled — Technical-layer concern | Persistence and construction belong in db-cell or runtime code. |
Where DNA intentionally differs
- DNA doesn't formalize Aggregates. Operations still respect aggregate-style consistency, but you don't draw the boundary explicitly — Relationships document associations, Rules enforce invariants.
- DNA doesn't distinguish Entity from Value Object at the schema level. Both are Resources; the distinction is in usage and matters at the Technical layer.
- DNA's Process is more concrete than DDD's Application Service. A literal DAG of named Steps with
startStep, conditions, and dependencies — closer to workflow notation than a service interface. - DNA elevates actors structurally. Actors (Roles, Users, Groups) live alongside business Entities. DDD typically pushes them to the application layer.
Concrete translation: A DDD model for the Lending bounded context maps cleanly to examples/lending/operational.json — Bounded Context → Domain, Aggregate roots → Resources, Domain services → Operations, Application service → Process, Specifications → named condition Rules.
BPMN
BPMN 2.0 (Business Process Model and Notation, OMG) is a graphical process-modeling notation. DNA is a textual description of the broader business — process is one concern among many. The two overlap most in DNA's Process / Step / Task primitives.
Concept mapping
| BPMN | DNA | Notes |
|---|---|---|
| Process | Process | 1:1. DNA adds explicit startStep and an owning Resource-as-Role. |
| Pool / Lane | Implicit via Task.actor | Swimlanes are computed by grouping Steps by their Task's actor — no separate primitive. |
| Task (atomic activity) | Step (orchestration) + Task (assignment) | BPMN conflates these; DNA splits. The same Task can appear in multiple Steps across multiple Processes. |
| Sequence Flow | Step.depends_on | BPMN draws arrows; DNA enumerates predecessor IDs. AND-joins fall out naturally. |
| Exclusive Gateway (XOR) | Step.conditions + Step.else | Gate lives on the Step rather than as a separate node. |
| Parallel Gateway (AND) | Multiple Steps with shared depends_on | Fan-out is implicit; fan-in is multiple IDs in depends_on. |
| Start Event | Process.startStep + a Trigger targeting the Process | Split: startStep names where execution begins; the Trigger says how it gets initiated. |
| Sub-Process | A separate Process chained via Trigger.source: operation | DNA doesn't nest Processes inline. |
| Boundary Events, Compensation | Not modeled | Runtime workflow concerns — deferred to the planned workflow-cell. |
Where DNA intentionally differs
- DNA is textual, BPMN is graphical. DNA round-trips through git diffs cleanly; BPMN diagrams don't.
- DNA separates orchestration (
Step) from assignment (Task). Same(actor, operation)binding can appear in many Steps across many Processes. - No Sub-Process primitive. Processes that trigger other Processes via Operation chaining force a clean boundary instead of nesting.
- Actors modeled structurally. Tasks reference Actor-Resources; Memberships pin Users to Roles within Groups — relationships BPMN doesn't formalize.
Tooling intersection: @dna-codes/dna-adapters/output/mermaid renders a flowchart per Process — recognizable to BPMN readers without claiming BPMN compliance. An input/bpmn adapter is not yet shipped; when written, it would surface each unmodeled construct (boundary events, inclusive gateways) as an explicit warning.
ArchiMate
ArchiMate 3 (The Open Group) is an enterprise-architecture modeling language spanning Business, Application, and Technology layers across active / behavior / passive concerns. DNA's three layers align loosely; ArchiMate is broader than DNA (it covers motivation, strategy, physical layers DNA doesn't model).
Layer alignment
| ArchiMate layer | DNA layer |
|---|---|
| Motivation, Strategy | Out of scope — supplementary docs |
| Business | Operational |
| Application | Product (Core, API, UI) |
| Technology | Technical (Cell, Construct, Provider, Environment) |
| Physical, Implementation & Migration | Out of scope |
Business-layer concept mapping
| ArchiMate | DNA | Notes |
|---|---|---|
| Business Actor / Business Role | Person + Role + Membership | ArchiMate distinguishes Actor (org entity) from Role (named function). DNA carries the distinction across separate primitives. |
| Business Collaboration | A Group with Memberships from multiple Roles | A temporary aggregate of Roles working together. |
| Business Process | Process (with Steps and Tasks) | 1:1 conceptually. |
| Business Service | Operation (when externally observable) | A discrete, externally-meaningful unit of behavior. |
| Business Object | Resource (with attributes) | A "concept used or produced by behavior." |
| Business Event | Trigger (initiation) + Operation.changes (state side) | ArchiMate Events are abstract "things that happen"; DNA splits initiation (Trigger) from state mutation. |
| Contract | Rule (access + condition); Signal payload schemas at Product layer | DNA formalizes the access/condition side as named, reusable Rules. |
When to reach for which
- Use ArchiMate for enterprise communication — motivation, strategy, multi-system landscape, stakeholder analysis.
- Use DNA when describing a system you intend to build, with rules tight enough to generate code, documentation, and workflows from.
- Use both — ArchiMate as the upstream architectural sketch, DNA as the downstream specification.
C4 Model
The C4 Model (Simon Brown, 2018) is a software-architecture diagramming technique with four levels: Context → Container → Component → Code. Where DNA describes the business and lets code generation handle the rest, C4 starts with software and zooms in.
Level-by-level mapping
| C4 level | C4 scope | DNA equivalent |
|---|---|---|
| Level 1: System Context | The system + its external dependencies | Domain + external-system Resources + cross-domain Triggers |
| Level 2: Container | Deployable units (apps, services, databases) | DNA Cell (Technical layer) |
| Level 3: Component | Major building blocks inside a Container | Not formally modeled — emerges from how Cells consume DNA |
| Level 4: Code | Classes / functions inside a Component | Out of scope — generated |
| Deployment / Dynamic / Landscape diagrams | Supplementary views | Deployment → Environment + Provider; Dynamic → Process flowcharts; Landscape → Domain hierarchy |
Where C4 is genuinely better
- Quick architecture communication. A C4 diagram gets across a system's shape in 30 seconds; a DNA document doesn't and isn't trying to. Render C4-style diagrams from your DNA for onboarding and exec briefings.
- Multi-system landscape. C4's Landscape diagram is more practiced than DNA's "many domains side-by-side" pattern.
- Decomposition conversations. When teams debate "one component or three" / "should this be its own container," C4 has the vocabulary.
Recommended workflow
- Sketch C4 Context + Container diagrams during architecture exploration.
- Convert once stable: Personas → Resources, Containers → Cells, adapters → DNA Technical adapters.
- Author DNA as the source of truth going forward; render C4-style diagrams from it.
- Keep C4 around for high-altitude conversations DNA isn't optimized for.
Event Storming
Event Storming (Alberto Brandolini, 2013) is a collaborative discovery workshop — teams cover a wall with colored sticky notes representing what happens in their domain. The output is structurally close to DNA: the colors map almost 1:1.
Sticky-note color → DNA mapping
| Sticky | Workshop name | DNA primitive |
|---|---|---|
| 🟧 Orange | Domain Event | No first-class event primitive in v1. State changes live in Operation.changes on the producing Operation. |
| 🟦 Blue | Command | Operation (Resource.Action) — verb side becomes Action. |
| 🟨 Yellow | Actor / User | Person or Role — workshop usually conflates them. |
| 🟪 Purple | Policy ("Whenever X, then Y") | Trigger (source: operation) targeting the downstream Operation. |
| 🟩 Light green | Read Model / Information | Not in Operational DNA — surface at Product UI Page or Product API Endpoint. |
| 🟫 Tan / Brown | Aggregate | Resource with attributes and actions. |
| 🟥 Red / Pink | Hot spot / Question | Not modeled — resolve before authoring DNA. |
| 🌐 Wide light blue | External system | Resource representing the integration + Trigger (source: webhook). |
Recommended workflow
- Run Event Storming as you normally would — don't bake DNA structure into the workshop.
- Take photos at workshop end. Resolve hot spots offline.
- Translate the wall into DNA in one pass, color by color (Tan → Resource, Blue → Operation, Yellow → Person/Role, Purple → Trigger, etc.).
- Validate with
@dna-codes/dna-core. - The first DNA pass usually surfaces gaps (un-scoped Roles, missing payload fields). Run a short follow-up with the team.
Where DNA exceeds the workshop output: Scoping (Memberships + Role.scope) — "Underwriter" on a sticky doesn't tell you Underwriter-of-what; DNA forces you to declare it. Step-level orchestration — Storming chains Commands via Policies (graph-shaped), DNA's Process introduces explicit startStep and depends_on. Explicit state mutations — Operation.changes forces the answer the workshop often leaves as "we'll figure it out."
TOGAF
TOGAF (The Open Group Architecture Framework) is a method for doing enterprise architecture — not a modeling language. DNA is one kind of artifact a TOGAF practice would produce in the Business / Information Systems Architecture phases. The two are complementary, not competing.
Where DNA fits in the ADM
| ADM Phase | DNA's role |
|---|---|
| Preliminary | Establish DNA as the canonical description format. |
| A. Architecture Vision | Out of scope. Vision documents are prose + ArchiMate sketches. |
| B. Business Architecture | DNA Operational is the deliverable — Resources, Operations, Roles, Processes. |
| C. Information Systems Architecture (Data + Application) | Data side: Resource + Attribute + Relationship. Application side: DNA Product documents. |
| D. Technology Architecture | DNA Technical documents — Cells, Constructs, Providers, Environments. |
| E. Opportunities & Solutions, F. Migration Planning | Out of scope. |
| G. Implementation Governance | DNA validation provides part of the conformance check. |
| H. Architecture Change Management | Out of scope. |
Architecture domain alignment
| TOGAF domain | DNA layer |
|---|---|
| Business Architecture | Operational |
| Data Architecture | Operational (Resource + Attribute + Relationship) |
| Application Architecture | Product (Core, API, UI) |
| Technology Architecture | Technical |
Where DNA exceeds TOGAF for a given system
- Executable specification. TOGAF deliverables describe what should exist; DNA describes what will exist and is the input to code generation.
- Cross-layer enforcement. A Product Resource must reference a real Operational Resource; an API Endpoint must reference a real Operation.
- Tighter actor model. TOGAF Actor/Role is loose; DNA's Memberships and
Role.scopecapture authorization-shaped invariants.
Where TOGAF exceeds DNA
- Governance, change management, capability management. TOGAF's value is largely in Phases A, E, F, G, H — none of which are DNA's job.
- Multi-system landscape. TOGAF's Architecture Continuum classifies reusable assets across many systems.
- Stakeholder + requirements management. Phase A and the central Requirements Management ring are workshop/tracker disciplines, not artifact shapes.