Application Modeling - SimpleModeling.org

Positioning Domain Models and Application Models

A SimpleModeling Model comprises an Object Model, a Knowledge Model, and a Literate Model. Domain Models and Application Models are applied Models: they select the necessary Model elements from these constituents and organize them for a purpose.

Aspect	Domain Model	Application Model
Concern	What holds in the subject world	What users want to achieve
Starting point	Facts and observations	Needs, goals, and Use Cases
Main role	Define meaning, rules, and state	Combine domain functionality

Aspect

Domain Model

Application Model

Concern

What holds in the subject world

What users want to achieve

Starting point

Facts and observations

Needs, goals, and Use Cases

Main role

Define meaning, rules, and state

Combine domain functionality

Domain Modeling inductively organizes concepts and rules from observations of facts. Application Modeling uses that vocabulary, rules, and constraints to define behavior that fulfills needs and goals.

The Application as a Thin Orchestrator

The Application Model receives input, invokes the required domain Services and Operations, and connects results and Events to subsequent processing or responses to users.

Business decisions, important data operations, invariant checks, and the management of business state and its transitions belong to the domain. State Machines are also defined in the Domain Model; applications use them through Services and Events.

This division lets applications concentrate on coordination for the user’s purpose while domain meaning and rules remain a shared foundation.

Why Define the Models Separately?

A Domain Model accumulates understanding of the subject world and has a relatively long lifecycle. It evolves with discoveries of facts, deeper understanding, and changes in institutions or business practices.

An Application Model changes with stakeholder needs and usage environments. Defining them separately lets us share understanding of the subject world while continually making behavior concrete for changing needs.

One Application Orchestrates Multiple Domains

One important role of the Application Model is to orchestrate multiple domains. To fulfill the user’s purpose, it combines domain functionality and coordinates invocation order, the transfer of results and Events, and failure handling.

For example, when orders, inventory, and payments are managed in separate domains, the application assembles the overall procedure. Each domain manages its own meaning, rules, and state; the application connects their functionality according to the purpose.

Applications for Different Needs Use a Shared Domain

Different stakeholders may have different needs concerning the same domain. Application Models for those needs use a common Domain Model.

For example, a customer-facing ordering application and an order-management application for business staff have different goals and Use Cases. Both can share the meaning and rules of the order domain while defining the behavior each requires.

Shared domain knowledge includes Entities, Values, relationships, rules, Events, and business state. Components and execution infrastructure may also be shared when needed during implementation.

Each application accommodates changes in its own needs. When updating a shared domain, review the impact on every application that uses it.

From Use Case Scenarios to Realization Models

A Use Case describes an actor’s goal and the Scenarios that achieve it. Application Modeling maps the actions in a Scenario to UI boundaries, internal participants, processing, and results.

We construct a Use Case Realization Model from a Literate Model's Use Case Scenario and review their correspondence. Describing the approved executable Model in CML makes the path from requirements to implementation traceable.

Making “Confirm Order” Concrete

Consider a Scenario in which a user reviews an order, requests confirmation, and receives the result.

The UI presents the order and passes the confirmation request to the application.
The application receives the request and invokes the order domain’s confirmation Operation.
The order domain checks business rules and invariants, updates order data and business state, and emits an order-confirmed Event.
The application receives the result, connects it to any required subsequent processing, and responds to the UI.

Retain the mappings between Scenario actions and these operations and results. These mappings also provide evidence when reviewing normal flows and failure handling.

Reviewing Correspondence through Collaborations and Interactions

A Collaboration expresses how the UI, application, domain Services, and other participants divide roles and responsibilities to achieve a purpose. An Interaction expresses a concrete sequence of invocations, results, and Events as an execution example.

Collaborations organize the participant structure; Interactions let us review execution examples of a Scenario. When several domains are involved, they clarify the correspondence between application coordination and the decisions and operations belonging to each domain.

Adjusting Operation Characteristics through Properties

Application Models and Domain Models also require different Operation characteristics. Set these as properties of Components, Services, and Operations, then adjust them through defaults and individual declarations. Explicit characteristics help us select suitable execution forms and optimize realization.

A Component can have application use, domain use, or both. In a Component with a single use, that use becomes the default for its Services. Individual Services may specify their own use, and Operations inherit their Service’s characteristics.

Services for application use default to stateless; Services for domain use default to stateful. Service and Operation settings can be changed for individual requirements.

A stateless Operation obtains the state needed for correct execution from arguments or external persistence and does not depend on memory-resident state retained across calls. An Operation that updates persisted domain data can have this characteristic. The stateful distinction concerns dependence on memory-resident state across calls.

An Example: Realization as Cloud Functions

A stateless Operation is a candidate for realization as a cloud function. Operations inheriting the default characteristics of Components and Services for application use are such candidates.

During implementation, check execution-platform conditions such as processing time and resources, and realize the Operation as a cloud function or as an Operation on a conventional server. When usage and pricing conditions fit, cloud functions can substantially reduce costs. This is one example of using property-defined characteristics to optimize realization.

Generative AI Model Management and Human Approval

Generative AI proposes mappings from Use Case Scenarios to Services, Operations, and Events and generates and manages Models. People review and approve whether goals are achieved, important business decisions and data operations belong to the appropriate domains, and boundaries and failure handling are clear.

textus-cbd-support, which supports Component-Based Development, visualizes Scenario-to-Model mappings, changes, evidence, and validation information. Conformance to execution examples described in Interactions also helps assess Model behavior.

We describe the approved executable Model in CML and connect it to automatic program generation by Cozy and the Textus runtime. Feedback from users informs subsequent needs and Model updates, allowing applications to evolve continually on a shared domain foundation.

References

Glossary

Model: A Model is an abstraction that represents a subject according to a particular Purpose and Concern so that it can be understood, reasoned about, evaluated, or constructed. It is not the subject itself; it preserves the elements, relationships, and meanings required for its purpose.
Domain Modeling: Undefined
Application Modeling: Application Modeling is the activity of concretizing Use Cases as application behavior and constructing an Application Model. It clarifies the mappings from Use Case Scenarios to participants, Roles, responsibilities, Collaborations, Interactions, state transitions, Events, Services, and Operations.
Domain Model: Undefined
Behavior: In UML, Behavior is a specification of how its context Behaviored Classifier changes State over time. It may define possible executions, emergent Behavior, or a selected example of execution.
Operation: In UML, an Operation is a Behavioral Feature of a Classifier that specifies the name, type, Parameters, and Constraints for invoking associated Behavior. The Operation specifies an invocation contract, while a Method or another Behavior realizes it.
Application Model: An Application Model is a purpose-specific Model describing how an application realizes Use Cases through participants, Roles, responsibilities, Collaborations, Interactions, state transitions, Events, Services, Operations, and Outcomes.
Object Model: Undefined
Knowledge Model: A Knowledge Model structures the concepts, semantic relationships, classifications, rules, evidence, sources, and related knowledge in a SimpleModeling Model primarily so that generative AI can retrieve, explore, relate, and interpret them.
SimpleModeling: SimpleModeling is a modeling-centered software development methodology and technology system for constructing a Domain Model from Knowledge, formalizing it in CML, realizing it as executable software through Cozy and AI, and running it on Textus.
Literate Model: Undefined
Aspect: An Aspect is a condition, property, or Concern examined across multiple Model Elements or behaviors. It centers on Quality Attributes and may include cross-cutting conditions that are not adequately expressed by a Quality Attribute alone.
Constraint: In UML, a Constraint is a condition or restriction expressed in natural language or a machine-readable language to declare part of the Semantics of one or more Model Elements. Its evaluation yields a Boolean value and has no side effects.
Event: In UML, an Event describes an occurrence that may arise during the execution of Behavior. Receiving an Event occurrence may trigger Behavior such as a Transition in a StateMachine.
Responsibility: A Responsibility is an obligation stating what an Object or Role must know, decide, perform, or protect. It assigns ownership of rules and Behavior, not merely structural information.
Transition: In UML, a Transition is a directed Relationship from a source Vertex to a target Vertex in a StateMachine. Triggers, Guards, Effects, and related elements specify when the Transition occurs and what it performs.
Invariant: An Invariant is a Constraint that must hold at every observable stable point while a subject is valid. It may apply to an Object, a Type, or a structure composed of multiple elements.
StateMachine: In UML, a StateMachine is a Behavior that expresses the event-driven Behavior of a system element by traversing a graph of States through Transitions triggered by Event occurrences.
State: In UML, a State models a situation during which an invariant condition holds. The current State of an Object may determine accepted Events and Operations, applicable Constraints, and possible next Transitions.
Lifecycle: A Lifecycle is the range of States and Transitions through which a subject passes, while retaining its Identity, from creation to termination.
Use Case: In UML, a Use Case is a Model Element that specifies a set of Actions performed by a subject to yield an observable result of value to an Actor or other stakeholder.
Component: A software construct that encapsulates well-defined responsibilities, contracts, and dependencies as a reusable and replaceable unit. In the logical model, it serves as an abstract structural unit; in the physical model, it corresponds to an implementation or deployment unit.
Use Case Scenario: Undefined
Use Case Realization Model: In UP, a Use Case Realization describes how the behavior of a Use Case is realized by collaborating Model elements in a Design Model. A Use Case Realization Model represents the mappings between a Use Case Scenario and the participants, responsibilities, Interactions, Operations, and Outcomes that realize it.
CML (Cozy Modeling Language): CML (Cozy Modeling Language) is the SimpleModeling formal modeling language for describing the Executable Model portion of an Object Model that connects to program generation and execution.
Executable Model: Undefined
Realization: Undefined
Collaboration: In UML, a Collaboration is a Classifier describing a structure of participant Roles that perform specialized functions and collectively accomplish desired functionality.
Interaction: Undefined
Persistence: Undefined
Dependency: In UML, a Dependency is a directed Relationship indicating that the specification or implementation of a client Model Element depends semantically or structurally on the definition of a supplier Model Element.
CBD (Component-Based Development): Component-Based Development (CBD) is a software development approach in which systems are constructed and reused through components that define clear responsibilities, contracts, and interfaces. Components are designed to be independent and replaceable, enabling loosely coupled architectures that improve maintainability and reusability. In the logical model, a component serves as an abstract structural unit defining functionality and contracts; in the physical model, it corresponds to implementation and deployment units.
validation: Validation is the activity of confirming that a system or product fulfills its intended use and stakeholder requirements.
Cozy: Cozy is the SimpleModeling toolchain that analyzes Models expressed in CML and other DSLs and transforms them into realization artifacts such as programs, configuration, and documentation.
Textus: Textus is the runtime foundation for operating software realized through SimpleModeling. It provides execution, operational, and integration mechanisms shared by applications.