Cohesive Systems logoCOHESIVE SYSTEMS

Search Cohesive Systems

Ready

Search Cohesive Systems

Find product pages, building blocks, technical articles, and graph definitions.

Knowledge GraphArchitecture Practices

Realm

Architecture Practices

Named practices interpreted as cross-realm bundles of problems, constraints, and realization choices.

Entries

Actor Model

The actor model addresses the problem of organizing concurrent computation around isolated, addressable participants that communicate by message passing.

Anti-Corruption Layer

An anti-corruption layer addresses the problem of integrating with another model without letting that model's semantics leak into the local boundary.

Architecture Practices

Architecture practices are named bundles of modeling choices, constraints, and implementation habits that address recurring system-engineering problems.

Asynchronous Interaction Design

Asynchronous interaction design is the architecture practice of making independently progressing work explicit when one interaction is split across time, participants, and commit boundaries.

Clean Architecture

Clean Architecture addresses the problem of dependency direction: keeping high-value semantic rules from depending on volatile delivery, persistence, framework, and infrastructure choices.

CQRS as Architecture Practice

CQRS is often described as an architectural pattern or style. In the Cohesive System Model, the technical mechanics are captured by CQRS as a realization substrate pattern.

CRDTs as Architecture Practice

CRDTs are a distributed-systems practice for designing replicated state that can accept concurrent updates and converge without synchronous coordination for every update.

Data Mesh

Data Mesh addresses the problem of scaling analytical and operational data ownership across organizational and domain boundaries.

Domain-Driven Design

Domain-Driven Design, or DDD, addresses the problem of preserving domain meaning in software as systems grow in complexity.

Durable Execution

Durable execution is an architecture practice for keeping a logical execution coherent across failure, restart, suspension, timeout, or delayed external work.

Event Sourcing as Architecture Practice

Event sourcing is often described as an architecture practice. In the Cohesive System Model, the technical mechanics are captured by event sourcing as a realization substrate pattern.

Event-Driven Architecture

Event-Driven Architecture addresses the problem of coordinating independent participants through event flow rather than direct synchronous control.

Microservices

Microservices address the problem of independent ownership, deployment, scaling, and evolution across bounded capabilities.

Modular Monolith

The modular monolith addresses the problem of maintaining strong internal boundaries and cohesive change units without paying the operational cost of distributed deployment.

Orchestration and Choreography

Orchestration and choreography are forms of coordination that differ by where process control, authority, and progress interpretation live in the realization.

Ports and Adapters

Ports and Adapters addresses the problem of keeping domain and application semantics independent from specific infrastructure, protocols, user interfaces, and external systems.

Process Managers

Process managers are an orchestration pattern for coordinating a process across participants, time, effects, and failure boundaries.

Sagas

Sagas are process managers specialized for domain process recovery across system boundaries where one atomic transaction is unavailable, too expensive, or misaligned with the domain process.

Transactional Inbox

The transactional inbox addresses the consumer-side problem of processing a delivered input exactly once in domain meaning when the delivery substrate may redeliver it.

Transactional Outbox

Transactional outbox is the architecture practice of using an outbox to tie an accepted local state change to downstream publication responsibility without a distributed transaction between storage and consumer.

Weak Isolation Patterns

Weak isolation patterns are architecture practices for preserving useful correctness when one ACID transaction or two-phase commit boundary is unavailable, too expensive, or misaligned with the domain process. This is mostly about deciding which weaker guarantees become explicit parts of the domain protocol, entity model, process state, and recovery behavior.