Zerya .NET DDD Architecture

Treat architecture as a set of evidence-backed model decisions, not a ladder from classes to projects. Keep semantic, consistency, ownership, and implementation boundaries distinct.

Establish domain evidence

1. Read repository instructions and accepted architecture decisions.
2. Identify the business problem, actors, outcomes, policies, terminology, and disputed meanings.
3. Consult domain experts or existing domain artifacts when available. Mark boundaries inferred only from code as hypotheses.
4. Map the relevant subdomains, candidate Bounded Contexts, upstream/downstream relationships, and language translations.
5. Trace representative commands, queries, events, external imports, and failure cases through the current implementation.
6. Record true business invariants, acceptable inconsistency windows, ownership, and independent lifecycles.

Read strategic-modeling.md when discovering or changing Bounded Contexts. Do not infer a context solely from folders, tables, teams, or deployment units.

Make separate decisions

Decide each axis on its own evidence: