01Requirement and scope control
Did the design start from explicit actors, use cases, constraints, and non-goals?
- Revisit
- The model starts before the primary behavior or boundary is clear.
- Developing
- The main use case is clear, but important constraints or non-goals remain implicit.
- Evident
- The design is driven by a bounded primary flow and revises scope when new evidence appears.
02Domain modeling
Do the concepts represent identity, values, state, and business rules instead of every noun?
- Revisit
- The model is a class inventory or mirrors storage without explaining domain meaning.
- Developing
- Most concepts are useful, but identities, values, or relationships need sharper boundaries.
- Evident
- Entities, values, and relationships form a small vocabulary that supports the required behavior.
03Responsibility and ownership
Is there one understandable owner for each decision, mutation, and invariant?
- Revisit
- State is mutated from many places or one god service owns unrelated behavior.
- Developing
- Primary ownership is visible, but one or two transitions or policies remain misplaced.
- Evident
- Responsibilities are cohesive and lifecycle ownership is explicit at every important boundary.
04Interface and dependency design
Are operations shaped by caller needs and dependencies directed toward stable contracts?
- Revisit
- Interfaces expose implementation detail or add abstraction without a caller or change force.
- Developing
- The main operations are usable, but dependency direction or error contracts need refinement.
- Evident
- Small interfaces make the primary flow clear and isolate genuine policy or integration boundaries.
05State and invariant correctness
Are legal states, transitions, and always-true conditions explicit and protected?
- Revisit
- Boolean combinations or public mutation allow illegal intermediate states.
- Developing
- The happy-path lifecycle works, but a transition or failure can still violate an invariant.
- Evident
- State changes are guarded by the owner and failures leave the model in a valid condition.
06Representative-flow validation
Was one end-to-end use case traced through calls, state changes, outputs, and a failure?
- Revisit
- The answer stops at boxes or types and never demonstrates connected behavior.
- Developing
- The happy path is traceable, but an important failure or state change is skipped.
- Evident
- A concrete walkthrough validates collaboration, state, output, and one boundary case.
07Appropriate pattern use
Does every named pattern answer a concrete variation, integration, lifecycle, or event pressure?
- Revisit
- Patterns are selected from memory before the problem establishes a need.
- Developing
- Most abstractions are justified, but one pattern adds more indirection than value.
- Evident
- The direct design comes first; patterns appear only where a named change force earns them.
08Concurrency judgment
Where relevant, is the shared state, harmful interleaving, and atomic owner named precisely?
- Revisit
- The design ignores a natural race or adds locks everywhere without identifying one.
- Developing
- The race is recognized, but the serialization or atomicity boundary is vague.
- Evident
- Concurrency is addressed proportionately at the invariant owner and omitted when it is not relevant.
09Error and idempotency handling
Do failure results, unchanged state, retries, and duplicate commands have explicit semantics?
- Revisit
- Generic exceptions or partial mutation make failure behavior unknowable.
- Developing
- Common errors are named, but retry or duplicate behavior remains ambiguous.
- Evident
- Callers can distinguish failures, retry safely where appropriate, and rely on preserved invariants.
10Testability
Can tests observe behavior and replace only genuinely external or variable collaborators?
- Revisit
- Tests would need real infrastructure or mock every internal class.
- Developing
- The main use case is testable, but time, policy, or failure seams are still implicit.
- Evident
- Deterministic contracts support happy-path, failure, invariant, and evolution tests.
11Extensibility and evolution
Does a follow-up change the smallest responsible boundary without speculative generality?
- Revisit
- The design either collapses under one change or pre-builds abstractions for imagined futures.
- Developing
- The follow-up is accommodated, but the affected responsibility or trade-off is not explicit.
- Evident
- The changed assumption, owning boundary, stable contract, and new cost are all explained.
12Communication and trade-offs
Are decisions, alternatives, uncertainty, and deliberate omissions easy to follow?
- Revisit
- Names and diagrams appear without the reasoning that connects them to requirements.
- Developing
- The approach is understandable, but alternatives or stopping decisions are under-explained.
- Evident
- The candidate narrates a coherent flow, compares defensible choices, and closes with clear boundaries.