The catalog

Every dimension the CAI measures.

The standard is composed of 124 dimensions across 10 lenses. Each is a definition — what it measures and how it's evaluated — pinned to a rubric version. This catalog is the standard's vocabulary; the spec documents how each folds into the score.

Showing only the Domain Modelling lens. Show all 124 dimensions →

Domain Modelling · 8 dimensions

ID	Dimension	What it measures	Why it matters	Evaluator
`DM1`	Aggregate boundariesmeta	Whether aggregates reference each other by identity (id) rather than by direct object reference — the core DDD consistency-boundary rule.	When this is weak, the parts of the domain that must stay consistent reference each other directly instead of by identity, so the rules that keep your data correct are easier to break.	tool
`DM2`	Strongly-typed idsmeta	How much of the domain uses strongly-typed ids vs raw Guid/string/int — adoption curve, not all-or-nothing.	When this is weak, much of the domain uses raw ids (plain strings, numbers, GUIDs) instead of strongly-typed ones, so it is easy to pass the wrong id and corrupt data without the compiler noticing.	tool
`DM3`	Integration-event couplingmeta	Whether cross-context integration events stay loosely coupled — no producer-owned enums/domain types leaking to consumers. Shared-kernel/contracts types are allowed.	When this is weak, cross-context integration events leak internal domain types to their consumers, so independent parts of the system become tightly coupled and harder to change apart.	tool
`DM4`	Rich vs anemic modelmeta	Whether aggregates/entities carry the behaviour that protects their invariants, rather than being data bags driven by external services.	When this is weak, the domain objects are little more than data bags whose rules live in external services, so the business rules that protect your data are scattered and easy to bypass.	tool
`DM5`	Encapsulated statemeta	Whether entities protect their state (private/init-only setters) instead of exposing public setters that bypass invariants. Softened when a rehydration framework (Marten/EF) is present.	When this is weak, domain objects expose their internal state through public setters, so other code can change them in ways that skip the rules meant to keep them valid.	tool
`DM6`	Domain ↔ infrastructure boundarymeta	Whether the domain layer stays free of infrastructure dependencies (EF/Marten/HTTP/ASP.NET) — the clean-architecture dependency rule.	When this is weak, the core business logic depends directly on technical infrastructure (database, HTTP, framework), so the rules at the heart of your system are hard to test and tied to specific technology.	tool
`DM7`	Repository granularitymeta	Whether repositories are per aggregate root (not per child entity) so the root's invariants can't be bypassed.	When this is weak, data access is not organised around the natural consistency boundaries, so the rules that protect your most important objects can be bypassed.	tool
`DM8`	Value-object opportunitiesmeta	Whether clusters of primitives that travel together (a missing value object) are extracted — a low-weight suggestion, LLM-confirmed when configured.	When this is weak, groups of values that belong together are passed around as loose primitives, so the same validation has to be repeated everywhere and is easy to get wrong.	LLM · advisory