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:
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:
API Surface | UI Surface |
Programmatic interaction | Human interaction |
DTOs | Views |
Commands | Buttons |
HTTP responses | Rendered state |
Status codes | Visual feedback |
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 → ProjectionValidation, 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 → FormsButtons 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:
- Map input to command
- Validate via transition metadata
- Check preconditions
- Apply concurrency policies
- Execute process
- Update projections
- 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:
- Semantic baseline (UI IR)
- Styling via CSS
- Renderer overrides
- Behavioral hooks
- 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