Cohesive Building Blocks

Most software engineers today agree on the following fundamental principles of good system design:

Separate concerns into distinct, well-defined components
Keep business logic focused on the domain and avoid mixing infrastructure concerns
Avoid duplicate transformation logic across different parts of the system
Avoid hidden magic and implicit behaviors that make systems difficult to reason about
Keep things portable and avoid tight coupling to specific frameworks or platforms
Make the system understandable to both current and future maintainers
Make boundaries explicit between different components and layers
Prefer explicit state and transitions rather than implicit state changes
Choose a single source of truth for each piece of information
Optimize for change by designing systems that can evolve over time
Fail fast and loud to surface problems early rather than hiding them
Treat observability as part of the design from the beginning, not as an afterthought
Test behavior, not wiring or implementation details
Make side effects deliberate and explicit rather than accidental
Keep dependencies directional and avoid circular dependencies

Cohesive doesn't introduce new buzzwords—it makes the concepts you already use explicit and structured.

Instead of scattering intent across services, pipelines, controllers, jobs, and database glue code, Cohesive organizes systems into clear building blocks. Each block has a defined responsibility and integrates predictably with others.

The Five Building Blocks
Why This Matters
Overview
Building Block Details
Source
References

The Five Building Blocks

Purpose: Enable domain-aligned system design by structuring systems around explicit semantic concepts rather than implicit framework rules. Each block represents a core concern in modeling, execution, and delivery.

Entities & Transitions: define domain entities and their state transitions explicitly, with invariants and lifecycle definitions. These define truth.
Relations: describe relationships between entities (not just database FK links) that govern how state and behavior connect across the model. These make that truth observable and queryable.
Processes: model workflows and long-running behaviors as first-class artifacts, not ad-hoc orchestration code. Processes coordinate behavior over time.
Presentation: separate concerns between domain execution and outward interfaces (APIs, UIs, integrations), ensuring projections are derived from canonical models. The presentation layer expose behavior externally.
Host: abstract the runtime environment that executes and monitors the above models consistently in production. The runs behaviors safely in production.

Each block has clear interfaces and integration points, reducing implicit logic and duplication.

Why This Matters

In many modern systems:

Business rules are scattered across services and handlers.
State transitions are implicit.
Projections are duplicated per interface.
Frameworks dictate structure instead of the domain.

Cohesive inverts that. The domain model becomes the center of gravity. Execution, presentation, and infrastructure orbit around it. For developers, this means fewer accidental complexities. For product managers, this means clearer business logic and healthier long-term systems.