Cohesive Systems

/

Cohesive Building Blocks

/

Cohesive Presentation

The Semantic Boundary of the System

The Domain defines structure and change. Processes coordinate execution. Relations define structured observation. The Host binds infrastructure.

Presentation is the semantic boundary of the system.

It translates between:

• External protocols ↔ semantic intent
• Semantic projections ↔ external representations

It is not a business layer. It is not orchestration. It is not infrastructure. It is the interface surface of semantics.

• The Semantic Boundary of the System
• Architectural Position
• Two Faces of the Same Boundary
• APIs: Semantic Protocol Translation
• UIs: Semantic Rendering
• Semantically-Driven UIs
• Shared Semantic Pipeline
• Contracts Derived from Semantics
• Stateless by Default
• Portability: Blazor and React
• Blazor
• React + TypeScript
• Extensibility Without Drift
• Clear Separation from Host
• Anti-Patterns Avoided
• Summary
• References

Architectural Position

Presentation sits:

• Above: Transitions, Processes, Relations
• Below: HTTP, gRPC, messaging, UI frameworks

It depends on:

• Transition definitions
• Process definitions
• Relation definitions

It does not depend on:

• Storage engines
• Event persistence strategy
• Durable runtime selection
• Index implementation

Presentation binds meaning, not infrastructure.

Two Faces of the Same Boundary

Presentation has two primary forms:

They are different interaction styles. They depend on the same semantic core.

APIs: Semantic Protocol Translation

APIs:

• Map external DTOs → typed transition or process inputs
• Invoke processes
• Return projections
• Define versioned contracts
• Translate transport concerns (status codes, headers)

They do not:

• Contain domain logic
• Coordinate workflows
• Perform storage access

An API endpoint is a semantic binding:

Route → Command → Process → Projection

Validation, preconditions, concurrency, and dispatch are pipeline concerns derived from semantics.

UIs: Semantic Rendering

UIs:

• Consume projections
• Render semantic structure
• Trigger transitions
• Reflect transition availability
• React to projection updates

They do not:

• Reimplement invariants
• Hardcode state checks
• Duplicate validation rules
• Mutate domain state directly

A UI screen is a semantic binding:

Route → Projection → Available Transitions → Forms

Buttons correspond to transitions. Forms correspond to command inputs. Availability corresponds to semantic preconditions.

Semantically-Driven UIs

Traditional UIs duplicate backend logic:

• if (Status == Tendered)
• Reimplemented validation rules
• Hardcoded field requirements
• Drift between frontend and backend

Cohesive removes duplication. Transition definitions determine:

• Available actions
• Required inputs
• Field types
• Validation rules
• Concurrency requirements

Relations determine:

• Screen shape
• Joined data
• Derived values

The UI becomes a semantic renderer.

Shared Semantic Pipeline

Both APIs and UIs rely on the same underlying pipeline:

1. Map input to command
2. Validate via transition metadata
3. Check preconditions
4. Apply concurrency policies
5. Execute process
6. Update projections
7. Return projection

APIs expose this as HTTP responses. UIs expose this as updated screens. Same semantics. Different surface.

Contracts Derived from Semantics

Because transitions and relations are first-class:

• API input contracts derive from transition definitions
• API output contracts align with projection definitions
• UI forms derive from command metadata
• UI layout reflects projection shape

This eliminates:

• DTO drift
• Validation duplication
• Conditional logic mismatch
• Divergence between frontend and backend

Presentation becomes a thin projection over semantics.

Stateless by Default

Both APIs and UIs rely on:

• Processes for coordination
• Relations for observation
• Host bindings for persistence

Presentation does not maintain workflow state. It translates and renders. This keeps it horizontally scalable.

Portability: Blazor and React

Presentation is not tied to a framework. The same semantic model can compile to:

Blazor

• Strongly typed components
• Generated forms
• Automatic dispatch
• C# source generation

React + TypeScript

• Generated component schemas
• Typed action dispatchers
• Availability gating
• Form generation

The UI IR is platform-neutral. Blazor and React are rendering targets.

Extensibility Without Drift

Cohesive supports layered extensibility:

1. Semantic baseline (UI IR)
2. Styling via CSS
3. Renderer overrides
4. Behavioral hooks
5. Optional JavaScript enhancements

Customization can change appearance and UX. It cannot:

• Override invariants
• Redefine transition availability
• Bypass validation
• Mutate domain state directly

Semantics remain authoritative.

Clear Separation from Host

Presentation:

• Defines interface semantics
• Translates protocols
• Shapes contracts
• Exposes intent

Host:

• Configures storage
• Selects execution runtime
• Wires messaging
• Defines deployment topology

Presentation defines what is exposed. Host defines how it runs.

Anti-Patterns Avoided

Without a disciplined presentation boundary:

• Controllers accumulate domain logic
• UI duplicates invariants
• Workflows leak into endpoints
• Storage concerns bleed upward
• Projection logic is rewritten in queries

Cohesive prevents this by:

• Making transitions first-class
• Making projections first-class
• Making availability first-class
• Keeping Presentation declarative

Summary

Cohesive Presentation:

• Is the semantic boundary of the system
• Exposes transitions and projections
• Treats APIs and UIs as symmetric surfaces
• Remains stateless and thin
• Separates interface from infrastructure
• Prevents logic leakage into controllers and frontend

The system speaks in transitions and projections. Presentation renders that language for both machines and humans — without redefining it.

References

Cohesive Systems Overview

Cohesive Host

Cohesive Entities & Transitions

Cohesive Processes

Cohesive Relations