Domain Modeling

Parts 5 through 7 covered the three constituents of a SimpleModeling Model.

From Part 8 onward, we organize the three constituents around development purposes. Domain Modeling focuses on what exists in the problem domain, what it means, and its structure and rules. State and behavior also belong in the Domain Model when they express the meaning of the subject itself. The next installment, Application Modeling, starts with user goals and Use Cases and focuses on realizing them through the UI and dynamic Collaborations and Interactions.

Previous article: 📄 Literate Modeling

Domain Modeling clarifies at least four aspects of the problem domain.

These four aspects are interdependent. For example, “customer” may mean different things in sales, contracts, billing, and support. The Context in which the term is used affects its attributes, relationships, and rules. Conversely, different rules attached to the same term may show that separate Contexts are needed.

The Object Model, Knowledge Model, and Literate Model are constituents of a SimpleModeling Model, each expressing a different aspect of the same subject. A Domain Model selects and relates the elements needed to understand and develop the problem domain from those three constituents; it is not another constituent at the same level.

This distinction keeps the Domain Model broader than a class diagram without turning it into one enormous document. Formal structure remains in the Object Model, semantic relationships and evidence in the Knowledge Model, and context and explanation in the Literate Model. Shared term identifiers and mappings between Model elements bring them together as one Domain Model.

Domain Modeling begins with terminology. A Glossary provides a common reference for identifying concepts and sharing their definitions, scope, and synonyms. Even words such as “relationship,” “association,” “ownership,” and “composition” are distinguished as Model concepts through Glossary identifiers.

When defining a term, associate it with the following information rather than relying on a single sentence.

Referencing the same identifiers from the Object Model, Knowledge Model, and Literate Model lets people and generative AI trace the same concepts.

A Context provides the background for interpreting terms and rules. A word’s meaning can change with the organization, business purpose, responsibilities, users, time, or legal system. Combining different business concerns under one definition without identifying their Contexts makes the Model unnecessarily complex.

A Bounded Context is the scope within which a Model's terms, structures, and rules have consistent meanings. Its boundary keeps meaning consistent inside and makes differences explicit when connecting to the outside; it is not simply a mechanical division of a system.

A Domain Model can include multiple Bounded Contexts when needed. Meaning remains consistent within each one, while mappings of terms and information across Contexts are made explicit.

Boundaries do not necessarily follow an organization chart or existing system divisions. Business responsibilities, reasons for change, groups of rules, and term meanings inform candidates, which are then adjusted against real examples.

Ubiquitous Language is shared by domain experts, developers, generative AI, Models, and programs within a Bounded Context. Registering terms in a Glossary alone does not establish it. The same meanings must be used in conversations, requirements, Models, CML, reviews, tests, and documentation. When meanings diverge, the terms and Model are updated together.

Ubiquitous Language does not unconditionally adopt every business term or impose implementation names on the business. Through collaboration, it preserves meaningful business distinctions while becoming precise enough for modeling.

The three constituents play distinct roles in one Domain Model.

For example, a business rule can be explained in the Literate Model, traced to its evidence and scope in the Knowledge Model, and expressed where needed as an executable constraint or behavior in the Object Model. Each constituent uses a suitable expression rather than duplicating the same prose.

Domain Modeling improves the Model's validity by moving between the following activities, rather than treating analysis as a single linear pass.

The order is flexible. Formalization can reveal ambiguous terms; examples can change a boundary; tracing evidence can uncover an exception to a rule. The reasons for updates and their impact must remain traceable.

Generative AI can read large collections of documents and terms and propose concepts, duplicates, contradictions, boundaries, and formal structures. In SimpleModeling, textus-bok turns literate information into a Knowledge Model accessible to generative AI, which primarily generates and updates the Object Model. AI generation and updates are integrated into the regular development loop instead of requiring people to write the entire Object Model from scratch.

textus-cbd-support presents developers with a visualization of the generated Model, differences from its previous version, evidence, affected areas, and validation results. Developers assess its structure, design intent, feasibility, and change impact, then return a revision direction to generative AI. Domain experts join the loop when business meaning or exceptions need their judgment.

The loop does not treat a generative AI answer as the authoritative Model. It uses generative AI as a principal Model author while retaining developer review and feedback. By preserving the relationships among terms, evidence, Model elements, reasons for change, and review results, AI updates become traceable development work.

Consider “Confirm Order.” In the sales Context, confirmation may be the business event in which a user finalizes an order and subsequent changes become restricted. In the payment Context, payment authorization matters; in the inventory Context, stock reservation matters. Collapsing all three into one “confirm” Operation obscures terms and responsibilities.

This organization lets sales, payment, and inventory retain their own Models while clarifying the information and responsibilities that cross boundaries. The next installment uses this Domain Model to express user goals as Use Cases and organize the collaboration of the UI, Services, Operations, and Events as an Application Model.

Part 9, “Application Modeling,” starts with user goals and Use Cases to construct an Application Model that realizes those goals through the UI and dynamic Collaborations and Interactions. It uses the Domain Model's state and behavior as a foundation while addressing coordination among the UI, Services, Operations, and Events.