Command and query responsibilities

Question and use cases

Both message types enter the same generated Mediator chain, then use different state ports.

Use this view when deciding whether a feature is a command, query, projection, or mixed responsibility.

Use the diagram during design review, incident diagnosis, code walkthroughs, and onboarding. It intentionally omits classes and projects unrelated to the focused question, so read it together with the source entry point and related topic pages.

This page covers only the named responsibilities and relationships; consult the relevant module documentation for capabilities not shown here.

Reading path

1. Step 1: Start with the shared Mediator entry and cross-cutting behaviors.
2. Step 2: Follow commands toward aggregates and write ports.
3. Step 3: Follow queries toward projections and read ports without assuming Dapper is mandatory.

Do not skip arrow direction, numbering, or group titles: they express dependency or time direction, execution order, and responsibility boundaries. If the diagram differs from current source or accepted architecture decisions, correct the generated catalog immediately.

Legend and notation

This is a CQRS diagram. Use that form to understand the layout, then test your interpretation against the source facts below.

Key relationships and design meaning

Relationship 1

Source fact: Commands and queries both enter the same generated Mediator implementation and fourteen registered behaviors.

Architectural meaning: One pipeline gives commands and queries the same authorization, validation, telemetry, and audit entry semantics unless markers explicitly skip work.

Review action: Does a query avoid changing domain state?

Relationship 2

Source fact: Command handlers modify aggregates through write ports; query handlers project data through read ports.

Architectural meaning: Write ports keep aggregate mutation and transaction behavior explicit instead of hiding writes inside projections.

Review action: Does a command return only the data needed to complete the use case?

Relationship 3

Source fact: Dapper is an available query adapter, not a universal requirement for every query.

Architectural meaning: Read ports allow projection-specific performance choices without imposing a second database or service boundary.

Review action: Can read optimization evolve without leaking into aggregate rules?

Design review questions

Answer each question when reviewing or implementing a related change. If code, tests, or an ADR cannot support the answer, do not decide from the diagram alone.

• Does a query avoid changing domain state?
• Does a command return only the data needed to complete the use case?
• Can read optimization evolve without leaking into aggregate rules?

How to use the answers

1. Identify the single owner of the capability or rule.
2. Confirm that dependency, call, or event direction does not reverse ownership.
3. Capture the conclusion with an automated test or repeatable command.

Boundaries and common mistakes

Boundary 1

Do not document different behavior counts unless the registration actually branches by message type.

• Do not infer: A connector in the diagram does not mean every implementation uses synchronous calls, a shared transaction, or shared data ownership.
• Review requirement: Does a command return only the data needed to complete the use case?

Boundary 2

CQRS separates responsibilities; it does not require separate databases or services.

• Do not infer: A connector in the diagram does not mean every implementation uses synchronous calls, a shared transaction, or shared data ownership.
• Review requirement: Can read optimization evolve without leaking into aggregate rules?

Source verification and regeneration

The primary verification entry point is BitzOrcas.Api/Composition/ApiPipelineRegistration.cs + Application contracts. Inspect it and its direct references before regenerating diagram assets and pages.

# Regenerate bilingual SVG, standalone HTML, and documentation pages
npm run diagrams

# Check locale pairs, references, safety attributes, accessibility, and canvas bounds
npm run verify:diagrams

# Confirm that generation changed only the intended diagrams and pages
git diff -- scripts/diagrams diagram-sources public/diagrams src/content/docs

# Verify internal links, MDX structure, and professional depth gates
npm run verify:docs
npm run audit:docs-depth

Change-completion checklist

• Responsibilities, order, states, and relationships match current source.
• Every new element helps answer this page’s question instead of turning the diagram into an inventory.
• Arrows have explicit direction and semantics without implying nonexistent synchronous or transactional guarantees.
• Chinese and English titles, labels, facts, and boundaries remain semantically equivalent.
• The diagram remains readable on narrow screens, in fullscreen, and while zoomed, with no overlap or overflow.
• Relevant architecture tests, integration tests, or verification commands have run.
• If a long-lived constraint changed, its ADR or architecture documentation is updated.

Continue reading

• Architecture overview
• All architecture diagrams
• Platform modules