The Standard in cCoder

Hassan Habib’s The Standard gives software teams a vocabulary for separating dependencies, business logic and exposure. cCoder uses that vocabulary extensively, while treating compliance as something demonstrated in code and tests—not claimed as a badge.

The useful idea is constrained responsibility

The Standard describes brokers that integrate with dependencies, services that hold business logic at increasing levels of composition, and exposers that present capability through APIs, user interfaces or other protocols. Foundations, processings, orchestrations and aggregations give each service a knowable reason to change. The value is not the folder structure itself. It is the constraint that information and responsibility move through the system deliberately. A controller should not quietly become a second business-logic layer. A foundation service should not coordinate an entire process. A broker should not decide business policy.

The Tri-Nature of Everything

The theory beneath The Standard is Hassan Habib’s Tri-Nature of Everything. A system has dependencies it relies upon, a purpose that legitimises its existence and an exposure through which other systems can consume what it offers. In software, The Standard materialises those three categories as brokers, services and exposers. The important extension is fractality. The pattern is visible when we zoom into one operation and when we zoom out across a distributed platform. Each system can be understood as a complete thing while also becoming a dependency within something larger.

How the tri-nature brings the cCoder stack together

At platform scale

cCoder.Data sits toward the dependency edge. It provides context factories, shared data models and platform infrastructure such as the metadata cache. It helps the stack survive by giving higher systems a reliable way to represent and reach their data, but it does not decide what a page, workflow or document means to the business. The independently published domain packages hold purpose. Content Management, Workflow, Security, Mail, Document Management and the other domains turn dependencies into recognisable capabilities. Their rules, permissions, events and tests explain why each system exists and how it can evolve. cCoder.Core brings those purposes to an exposure boundary. It composes the domain APIs and background capabilities into supported Web, HostedServices and Workflow execution hosts. Applications receive a coherent platform without Core absorbing the business logic owned by its constituent domains.

At domain scale

Zoom into cCoder.ContentManagement and the tri-nature appears again. Its storage and authorisation brokers are dependencies. Its foundation, processing, orchestration and coordination services implement purpose. Its OData controllers and page renderer are exposers. This is what allows a specific business capability to be offered as pure business logic. Page hierarchy, path construction, layout validity, access rules and update events do not depend on HTTP or Entity Framework. They live in services that accept domain values and return domain results. The exposure can change protocol and the dependency can change storage without either redefining the purpose.

At operation scale

Zoom into one page update and the pattern repeats once more. PageBroker fulfils the dependency role by persisting the resource. The page service chain validates, authorises, constructs the path and raises the event to fulfil the operation’s purpose. PageController exposes that capability through OData. The operation is therefore both a complete tri-nature in its own right and one small purpose within Content Management. Content Management is itself a purpose within the wider cCoder stack. That repeated shape is how the platform grows without becoming one indistinguishable body of code.

A practical placement test

When deciding where code belongs, ask what would cause it to change:

1. An external dependency or storage technology changed: place the integration behind a broker.
2. The rules for one resource changed: place validation and single-resource operations in a foundation service.
3. Several operations within one domain must be combined: use processing.
4. A business action coordinates several capabilities or side effects: use orchestration.
5. The way callers reach the capability changed: keep that concern in an exposure such as a controller.

This test is more useful than asking whether a class “looks clean” because it ties placement to dependencies, responsibility and likely change.

A worked example: updating a content page

The current Content Management domain makes the path visible. An update entering PageController is not implemented in the controller. The controller accepts the OData request, establishes the page identifier and delegates to the page orchestration service.

Each layer adds a different kind of knowledge. Removing one would move that knowledge somewhere less appropriate; adding the same knowledge to two layers would create competing sources of truth. That is the architectural test that matters.

How to recognise layer drift

A codebase is usually drifting when controllers know about persistence, storage brokers contain policy, simple resource rules require a complete application host to test, or the same validation appears at several entry points. Those symptoms reveal mixed reasons to change even when the directory names still look correct. cCoder’s recurring shape—brokers, foundations, processings, orchestrations and exposures—makes those departures easier to spot during review. An unfamiliar repository is also quicker to navigate because a reader can predict where integration, policy and entry-point code should live.

Tests are part of the architecture

Layer boundaries become credible when they can be tested independently. The active cCoder domains pair service-level unit tests with acceptance and integration hosts covering API contracts, event delivery and cross-process flows. cCoder.Core then verifies that the published package graph runs as composed Web, HostedServices and Workflow execution hosts. A useful rule is to test at the narrowest boundary that can prove the behaviour. Test resource rules against the foundation service, coordination against the orchestration service, and reserve full integration tests for behaviour that genuinely crosses processes or packages.

Adopt the reasoning, not the ceremony

cCoder is a platform family rather than a single tutorial service, so its domains also need composition roots, hosted processes, OData metadata, event providers and package-import flows. Some historical areas still carry naming or layering debt and are being aligned incrementally. The Standard should not be used to manufacture empty layers. If a service adds no distinct responsibility, the extra abstraction has not yet earned its place. The goal is a dependency graph that explains the system, supports focused testing and makes change safer.

A review checklist you can use

• Can this class be described with one reason to change?
• Does it depend only on the layer immediately below the responsibility it coordinates?
• Is business policy absent from brokers and exposure code?
• Can its behaviour be tested without unrelated infrastructure?
• Would a new engineer know where to look for the next change of this kind?

If those answers are clear, the architecture is doing useful work. If they are not, renaming folders will not fix it; responsibility and dependency direction need to be reconsidered. The Standard is maintained openly by Hassan Habib. cCoder’s interpretation can be inspected in the domain repositories and will continue to evolve with them.