Výběr sekce

Domain Context template

Purpose

  • this artifact exists to unify understanding of the project domain
  • it serves as shared context for all following roles in the pipeline
  • it explains what kind of problem is being solved, why it is being solved, and which terms must be understood consistently
  • it does not serve as a technical specification of the solution
  • it does not serve as an implementation design
  • it does not serve as a source of new requirements

Domain Summary

  • the domain is the broader problem area in which the project operates
  • the goal is not only to build a specific solution, but to solve a meaningful domain problem in a sustainable and understandable way
  • the project should reflect real domain needs, constraints, and terminology
  • the business problem is that without a clearly defined domain context, analysis, implementation, testing, and documentation tend to drift apart
  • the main purpose is to create a stable reference layer that keeps all later work aligned with the actual nature of the domain

Domain Principles

  • the domain must be described in terms of purpose, meaning, and boundaries
  • the context must stay general, stable, and useful over time
  • the domain description must not drift into technical implementation detail
  • the goal is not maximum detail, but consistent and durable understanding
  • no part of the context may introduce hidden scope expansion

Objective

  • the objective in this domain is to define what the project is really about from a business and conceptual perspective
  • the context focuses on purpose, scope, meaning, and expected interpretation
  • correct understanding means that the domain can be interpreted consistently by different roles and artifacts
  • the objective is not to prescribe implementation details
  • the objective is not to replace analytical, design, or development documentation

Validation Scope

  • the domain context covers:
    • purpose of the domain
    • business meaning of the project
    • key concepts and entities
    • boundaries, expectations, and interpretation rules
  • the domain context does not cover:
    • repository structure
    • implementation details
    • concrete tasks or backlog items
    • temporary project decisions
    • technical design of modules
    • test cases or execution logic

Core Concepts

Domain

  • the broader problem space in which the project exists
  • in this context it represents the real-world meaning behind the solution
  • it is often confused with implementation scope
  • domain is wider than a specific feature or module

Business Problem

  • the real problem or need that the project is intended to address
  • in this context it explains why the project exists
  • it is often confused with a bug, task, or technical limitation
  • business problem defines purpose, not implementation

Project Objective

  • the intended outcome the project should achieve within the domain
  • in this context it connects the problem with a meaningful direction
  • it is often confused with a technical milestone
  • objective explains what should be achieved, not how

Scope

  • the set of things that are intentionally included in the project domain
  • in this context it defines what belongs to the solution space
  • it is often confused with implementation backlog
  • scope determines relevance, not execution detail

Boundary

  • a limit that defines what is outside the domain or outside the intended purpose
  • in this context it prevents uncontrolled expansion
  • it is often confused with a technical limitation
  • boundary protects the integrity of the domain

Constraint

  • a rule, condition, or limitation that must be respected
  • in this context it reflects reality that shapes the solution space
  • it is often confused with an implementation decision
  • constraint affects possible solutions, not just coding choices

Stakeholder

  • a person, role, or group affected by the project or its outputs
  • in this context stakeholders give the domain its practical meaning
  • it is often confused with a delivery role in the pipeline
  • stakeholder relevance comes from business impact, not tool ownership

Artifact

  • a document or output that captures some part of understanding, design, implementation, or validation
  • in this context it is a container of knowledge, not the knowledge itself
  • it is often confused with the domain definition
  • artifacts should align with the domain, not redefine it

Key Entities

Project

  • the concrete initiative being developed
  • it is important because it applies the domain in practice
  • it is tied to goals, constraints, and outputs

Problem Area

  • the area of reality the project is trying to address
  • it is important because it defines relevance and purpose
  • it is tied to business need and expected value

User or Consumer

  • the person or role that uses, reads, or benefits from the project output
  • it is important because the project exists for some real usage
  • it is tied to expectations, value, and interpretation

Knowledge Artifact

  • a persistent document or output carrying information about the project
  • it is important because the project must remain understandable over time
  • it is tied to analysis, implementation, testing, and long-term continuity

Rule or Constraint

  • a limiting or shaping condition within the domain
  • it is important because it defines what is acceptable or valid
  • it is tied to interpretation, scope, and decision-making

Relationships

  • the project exists within a specific domain
  • the domain is defined by a business problem, objectives, boundaries, and constraints
  • stakeholders give meaning to the project and its outputs
  • artifacts capture knowledge about the project, but do not replace the domain itself
  • scope defines what is relevant within the domain
  • boundaries and constraints prevent invalid interpretation and uncontrolled expansion

Typical Business Flow

  • a project starts from a real problem or need
  • the domain is described so that its purpose and meaning are explicit
  • the project objective is interpreted within the boundaries of that domain
  • analysis, implementation, testing, and documentation are then created in alignment with this context
  • outputs are evaluated not only by technical correctness, but by whether they still make sense in the domain
  • the result is a project that remains understandable, relevant, and governable over time

Business-Relevant States

Domain Not Defined

  • the project exists, but its domain meaning is unclear
  • from a business perspective this creates risk of inconsistency and scope drift

Domain Defined

  • the project has an explicit domain context
  • from a business perspective this creates shared understanding and stable direction

Domain Misinterpreted

  • the domain exists, but roles or artifacts interpret it differently
  • from a business perspective this creates confusion, invalid assumptions, and weak alignment

Domain Respected

  • decisions and outputs stay aligned with the defined domain
  • from a business perspective the project remains coherent and meaningful

Domain Violated

  • work extends beyond or against the defined domain boundaries
  • from a business perspective the project loses focus and reliability

Result Interpretation

  • VALID → the project or artifact remains aligned with the stated domain, purpose, and boundaries
  • INVALID → the project or artifact contradicts the domain, exceeds its scope, or misinterprets its meaning
  • UNKNOWN → the available information is not sufficient to determine alignment with the domain
  • interpretation always depends on purpose, boundaries, and stated meaning
  • interpretation does not replace analysis or implementation review, but provides context for both

Terminology Notes

  • prefer domain context over vague project background
  • do not use domain interchangeably with implementation scope
  • do not use objective interchangeably with technical solution
  • do not use artifact interchangeably with requirement
  • do not treat domain context as backlog, specification, or design note
  • keep terminology stable across documents and roles

Boundaries and Non-Goals

  • this context does not define repository structure
  • it does not define naming conventions for files or folders
  • it does not define implementation design
  • it does not define test strategy
  • it does not define release process
  • it does not define temporary tasks, fixes, or priorities
  • it is not an analysis, specification, or design document
  • it is not a source of new requirements

Usage in Pipeline

  • it is read by all roles that need shared domain understanding
  • it is used to align terminology and interpretation
  • it helps keep the difference clear between domain meaning and technical execution
  • it is informative
  • it is not directive
  • it must not be used as a replacement for analysis, specification, or implementation documents

Interpretation Guardrail

  • domain_context.md must not be used as a source of new requirements
  • no role may use domain_context.md to expand scope beyond the explicitly approved task
  • domain_context.md serves only to:
    • unify terminology
    • explain the domain
    • preserve consistent interpretation
  • if another artifact conflicts with domain_context.md in terms of meaning, the conflict must be explicitly resolved, not silently ignored

Strict Scope Enforcement

  • the domain context is limited to explaining the domain and its interpretation
  • this scope must not be expanded into implementation, analysis, or delivery instructions
  • no role may:
    • derive new features directly from domain_context.md
    • treat domain_context.md as a specification
    • treat domain_context.md as a design proposal
    • treat domain_context.md as a testing plan
  • any attempt to use domain_context.md outside this purpose must be treated as scope violation