Search docs
Docs searchValidation category
Domain Model Quality
Review implemented validation rules for anemic models, aggregate boundaries, oversized boundaries, scattered domain logic, and cross-aggregate writes.
Domain Model Quality findings make business responsibilities and aggregate ownership easier to review across modules.
Overview
Review implemented validation rules for anemic models, aggregate boundaries, oversized boundaries, scattered domain logic, and cross-aggregate writes.
Domain Model Quality findings make business responsibilities and aggregate ownership easier to review across modules.
Why it matters
Cloud uses this guidance to help teams interpret local validation findings in organization context without turning the docs into implementation notes.
When this domain drifts, findings become harder to triage, ownership becomes less clear, and architecture review depends too much on individual memory.
Good architectural practices
- Domain objects and services that own business invariants.
- Aggregate boundaries respected by workflows.
- Domain logic centralized instead of scattered across layers.
Common anti-patterns
- Anemic domain model
- Aggregate boundary violation
- Oversized aggregate/service boundary
- Domain logic scattered across layers
- Cross-aggregate modification risk
Relationship to other architecture areas
This domain usually overlaps with neighboring validation categories. Use the related pages below to understand the adjacent architecture concerns before changing policy, suppressing a finding, or accepting risk.
Implemented rules
These are the currently implemented rules in this category. Use this table for category-level orientation, then open the Rule Catalog when you need rule-specific examples and remediation guidance.
| Rule ID | Rule title | Category | Severity | Short explanation | Example violation | Remediation guidance | Rule detail |
|---|---|---|---|---|---|---|---|
| AP-DOM-001 | Anemic domain model | Domain Model Quality | warning | Flags domain objects that appear to expose data without owning behavior or invariants. | Every service checks subscription status differently before changing billing state. | Move invariant checks into the domain object or focused domain service. Keep DTOs separate from domain behavior. Add tests around the domain rule being protected. | View rule page |
| AP-DOM-002 | Aggregate boundary violation | Domain Model Quality | warning | Flags code that reaches across aggregate boundaries instead of using the owning boundary. | Billing code directly mutates organization invitation state. | Route changes through the aggregate that owns the invariant. Use domain events or application services for cross-aggregate coordination. Keep read models separate from write decisions. | View rule page |
| AP-DOM-003 | Oversized aggregate/service boundary | Domain Model Quality | warning | Flags domain or service boundaries that appear too broad for one aggregate responsibility. | WorkspaceService owns billing, invitations, repository upload, and policy exceptions. | Identify cohesive responsibility groups. Extract separate aggregates or services for unrelated behavior. Keep coordination in application services, not oversized domain objects. | View rule page |
| AP-DOM-004 | Domain logic scattered across layers | Domain Model Quality | warning | Flags business rules repeated across controllers, services, repositories, or UI code. | Free-plan repository limits are checked separately in UI, API route, and database helper code. | Choose one domain or application boundary for the rule. Replace duplicated checks with calls to that boundary. Add tests that cover the centralized rule. | View rule page |
| AP-DOM-005 | Cross-aggregate modification risk | Domain Model Quality | warning | Flags workflows that modify multiple aggregates without clear coordination. | One method directly updates organization, billing subscription, and invitation records with no coordination model. | Move coordination into an application service. Use events/outbox for eventual consistency when appropriate. Keep each aggregate responsible for its own state changes. | View rule page |
Related pages
Next steps