Modern systems are often described through implementation styles: CRUD, DDD, Event Sourcing, CQRS, Actors, RPC, Pub/Sub, Sagas, Durable Execution, Outbox, and so on.
These are usually presented as competing architectural choices. Cohesive treats them differently.
They are not separate worlds. They are different realizations of a deeper system model: entities, shapes, relations, transitions, effects, invariants, histories, and coordination constraints.
The important question is not:
Which architecture should this system use?
The better question is:
What semantic structure does the system have, and which realization preserves that structure under the required operational constraints?
Cohesive makes this correspondence explicit. A transition can be realized through a simple state update, an event stream, a transactional outbox, an actor message, a durable workflow step, or a projection pipeline. The semantic model remains the source of truth, while the realization model determines durability, ordering, isolation, replay, distribution, and recovery.
Traditional software architecture often separates domain logic from infrastructure. That separation is useful, but incomplete.
Cohesive models the relationship more tightly:
Semantic system <-> Realization systemThe semantic side describes what the system is:
The realization side describes how the system is executed:
The two sides are systematically connected. A transition's read/write set implies concurrency constraints. A concurrency constraint implies possible execution strategies. A workflow's compensation requirements imply a process model. A query shape implies a projection. A partitioning strategy constrains which transitions can be executed atomically.
Cohesive makes these correspondences first-class.
Instead of treating CRUD, DDD, Event Sourcing, Outbox, CQRS, Actors, RPC, Pub/Sub, Sagas, and Durable Execution as mutually exclusive architectures, Cohesive separates the realization problem into four dimensions.
Each dimension answers a different question:
Named patterns are common bundles of mechanisms across these dimensions. A real system usually composes several bundles at different points in the graph.
Persistence describes the durable record of the system. It can preserve current state, history, process progress, pending integration work, or derived query surfaces.
Common mechanisms include:
Not every runtime that owns state provides persistence. For example, actors own identity-scoped runtime state, but durability requires a state provider, snapshot store, event history, or another external persistence mechanism.
Reconstitution describes how executable state is recovered from durable records, runtime identity, or another system's own storage model.
Common mechanisms include:
Reconstitution is separate from persistence because the same durable record can support more than one reconstruction strategy. An event history can rehydrate an aggregate, rebuild a projection, drive an audit view, or resume downstream consumers.
Coordination describes orchestration and interaction between nodes. It covers the ordering of effects, the handoff between components, the boundaries of atomic work, and the recovery behavior when part of the interaction fails.
Common mechanisms include:
This is where many architectural names become precise. CRUD does not define cross-node coordination. DDD does not define it by itself either; DDD can be paired with CRUD, outbox, event sourcing, CQRS, actors, workflows, or another realization style. Outbox and event sourcing are salient partly because they couple persistence to coordination instead of treating side effects as loose code after a write.
Runtime describes the substrate that executes the selected mechanisms. It is where storage clients, dispatch loops, schedulers, queues, workers, actors, workflows, projections, and protocols become operational.
Common mechanisms include:
Infrastructure components provide runtime capabilities, but they are not architectures by themselves. A database, broker, actor runtime, or workflow engine becomes part of an architecture only when it is bound to semantic requirements.
A named pattern is a reusable composition across the four dimensions, not a complete description of a system.
CRUD
Persistence: current-state rows or documents
Reconstitution: load the latest record
Coordination: none specified, or ad hoc side effects around service methods
Runtime: application server plus database transaction managerDDD
Persistence: aggregate state behind repositories or adapters
Reconstitution: load an aggregate root and enforce invariants through behavior
Coordination: aggregate-local commands; cross-node coordination supplied by another style
Runtime: application services, domain objects, repositories, and units of workEvent Sourcing
Persistence: append-only event history
Reconstitution: replay events, optionally after loading a snapshot
Coordination: appended events drive handlers, subscribers, and projections
Runtime: event store, stream processors, projectors, and subscribersOutbox
Persistence: domain state and integration messages in one atomic write boundary
Reconstitution: resume publication from unprocessed outbox records
Coordination: transactional write first, durable asynchronous dispatch later
Runtime: database transaction plus dispatcher, poller, queue, or change-feed processorCQRS
Persistence: command-side state plus separate read-model projections
Reconstitution: rebuild read models from events, change feeds, or command-side changes
Coordination: commands mutate write models; projections update query models asynchronously
Runtime: command handlers, projection workers, read-model stores, and query APIsActors
Persistence: identity-scoped runtime state; durability requires a state provider or event history
Reconstitution: activate actor by identity and optionally rehydrate durable state
Coordination: messages route through identity-scoped mailboxes with ordering
Runtime: actor runtime with placement, mailboxes, supervision, and state providersRPC
Persistence: none specified; each callee owns its own persistence
Reconstitution: callee reconstructs state through its own mechanism
Coordination: direct request/response interaction between caller and callee
Runtime: HTTP, gRPC, service mesh, SDK client, or transport-specific runtimePub/Sub
Persistence: retained streams or logs when the broker supports retention
Reconstitution: resume from offsets or replay retained messages
Coordination: producers and consumers interact indirectly through topics and streams
Runtime: broker or stream runtime with producers, consumers, partitions, and subscriptionsSaga
Persistence: process state, step state, pending effects, and compensation records
Reconstitution: reload the saga instance and its current compensation plan
Coordination: process manager coordinates distributed steps and compensating actions
Runtime: process manager, workflow engine, actor, or message-driven coordinatorDurable Execution
Persistence: workflow history, checkpoints, timers, and activity results
Reconstitution: replay workflow history or resume from checkpoints
Coordination: orchestrator coordinates activities, timers, retries, signals, and recovery
Runtime: durable workflow engine with schedulers and activity workersA real system often uses several compositions simultaneously. For example, a freight tender workflow might use:
Without a higher-level model, these mechanisms become tangled implementation choices. With Cohesive, they become realizations of explicit semantics.
Infrastructure components are not architectures by themselves. They are runtime layers where architectural styles can be realized.
Cohesive does not ask developers to choose one architectural style globally.
Instead, Cohesive defines the system graph first.
Shape
-> Entity
-> Transition
-> Effect
-> Relation
-> Projection
-> Runtime realizationA transition might say:
AcceptTender
Reads:
Tender.Status
Tender.Expiration
PartnerPolicy.AcceptanceRules
Writes:
Tender.Status = Accepted
Tender.AcceptedAt
Load
Emits:
TenderAccepted
LoadCreated
Effects:
Send990Accept
StartTrackingFlow
Preconditions:
Tender.Status == Pending
Tender.Expiration > nowFrom this one semantic definition, different realizations become possible.
Load current Tender
Validate preconditions
Create Load
Update Tender
Commit transaction
Return responseThis is suitable when the transition is local, synchronous, and transactionally simple.
Load current Tender
Validate preconditions
Create Load
Update Tender
Append Outbox(TenderAccepted, LoadCreated)
Commit transaction
Dispatch messages asynchronouslyThis is suitable when domain state and external propagation must not be dual-written unsafely.
Load Tender event stream
Reconstitute Tender state
Validate preconditions
Append TenderAccepted
Append LoadCreated
Project current state and read modelsThis is suitable when history, replay, auditability, or temporal reasoning are core requirements.
Route AcceptTender command to Tender actor
Actor loads or already owns Tender state
Actor validates transition
Actor persists state or events
Actor emits effectsThis is suitable when identity-scoped concurrency control and message ordering are central.
Start AcceptTender workflow
Validate tender state
Execute Send990Accept activity
Create Load activity
Record progress
Retry failed activities
Compensate if required
Resume after crash or delayThis is suitable when the transition expands into a long-running, failure-prone, multi-step process.
In a conventional architecture, choosing between CRUD, Event Sourcing, Actors, CQRS, and Durable Execution is often a manual design decision.
In Cohesive, the system model provides enough structure to make the choice more systematic.
A transition with only one entity, one partition, no external effects, and no long-running steps can be realized as a direct transactional update.
A transition with external messages should use an outbox or equivalent reliable propagation mechanism.
A transition whose history is semantically significant should be event-sourced or emit durable domain events.
A transition with identity-local concurrency requirements can be realized through an actor.
A transition with timers, retries, human actions, or compensations should be realized through a durable workflow or process manager.
A query shape that diverges from the write shape should be realized as a projection.
A high-volume integration stream should be realized through Pub/Sub or event streaming infrastructure.
The semantic model does not erase architectural choice. It makes the choice inspectable, explainable, and eventually compilable.