Conceptual Model/Analysis Model/Design Model
A domain model is a representation of the real world transformed into a model that can be manipulated by software. The key point is to faithfully reproduce the "conceptual world" held by experts in the target problem domain.
By constructing such a model, it becomes possible to share it with experts, thereby enhancing the consistency and understanding in software development.
Domain Model Creation Conditions
Of course, simply reproducing the conceptual world faithfully is not enough to make it operational in software, so various adaptations are made.
The conditions for creating a domain model can be summarized as follows:
-
Faithfully reproduce the conceptual world of the problem domain so that it can be shared with domain experts
-
Establish it as a mechanism that can be implemented in software
There are various options for modeling the problem domain, such as granularity and perspective, but it must fit within a structure that operates in software.
Therefore, it is practical to proceed with modeling according to a predefined model framework template that works in software.
Model Layers in SimpleModeling
In SimpleModeling, domain models are implemented in the following three layers.
-
Conceptual Model
-
Analysis Model
-
Design Model
The diagram below shows the types of model elements used in the conceptual, analysis, and design models within SimpleModeling.
Details will be explained in another article, but the types of model elements used increase dramatically as the level of concreteness rises from the conceptual model to the analysis model and then to the design model.
Each of the conceptual, analysis, and design model layers has different purposes and users depending on its level of abstraction.
Here, we explain the characteristics and operational methods of each.
Conceptual Model
The conceptual model is used in the disciplines of business analysis and requirements analysis.
It represents the structural elements of the problem domain — such as business structure, participants, resources, and rules—in an abstract and intuitive manner.
The conceptual model has the following objectives:
-
Provide an overview of the domain model, clarifying the business structure and background context.
-
Facilitate information sharing with stakeholders, such as business owners, who are not involved in development details.
-
Ensure continuity with implementation approaches that connect directly to the analysis and design models as concreteness increases.
Establishing a ubiquitous language is a key theme in the conceptual model.
By clarifying terminology definitions, misunderstandings and requirement misalignments are prevented.
Moreover, ensuring continuity between terminology and system implementation objects helps prevent discrepancies between the conceptual model shared among stakeholders and the final implementation.
Focusing on terminology definitions, the classification structures of classes and diagrams are used to visualize the structure of complex business operations.
The model is presented in a format that is easy to understand, even for non-technical stakeholders.
Analysis Model
The analysis model is a model that clarifies the functions and structure of an application.
It creates a pure model for realizing an application, keeping a distance from execution environments such as runtime platforms and implementation languages, cross-cutting concerns such as performance and security, and non-functional requirements.
It corresponds to a PIM (Platform Independent Model).
The basic structure of the model is a concretization of the conceptual model, and continuity with the conceptual model is important.
It ensures that the structure and mechanisms of the conceptual model shared among stakeholders link directly to the realization of the system.
In the analysis model, the structure of the domain model is detailed and concretized in a way that does not depend on implementation technology, and the behavior of the domain model is defined.
-
Describe the basic structure of the domain using entities and values.
-
Use model elements such as datatypes, state machines, and powertypes to concretize the structure and behavior of entities.
-
Use subsystems and components to clarify the boundaries of the domain model.
-
Use events, workflows, and services to concretize the behavior of the system.
-
Use rules to define the constraints and regulations of the domain.
-
Incorporate cloud-native elements as needed.
The analysis model is used in discussions with stakeholders such as on-site customers and domain experts who are responsible for the internal structure and non-functional requirements of the system.
Design Model
The design model is a model that, based on the execution environment such as the runtime platform and implementation language, refines the analysis model into a form that can run in the execution environment.
It corresponds to a PSM (Platform Specific Model).
The highly abstract model created in the analysis model is concretized for the execution environment.
It is described in alignment with the technology stack to be used, such as databases, APIs, and web frameworks.
In the SimpleModeling reference model, the design model is created for the following execution environment.
-
Programming language: Scala 3
-
Core library: Cats
-
Framework: Cloud-Native Component Framework (SimpleModeling)
Scala 3/Cats is introduced by integrating full-scale functional programming into object-oriented programming.
Since middleware such as databases and cloud platforms is abstracted by the Cloud-Native Component Framework (CNCF), the design phase targets CNCF-based design.
The foundation of the design model consists of Scala programs automatically generated from the analysis model by Cozy.
In the design phase, this framework is enriched through Scala programming, with supplementary information described using UML or similar as needed.
The design model implements the following elements:
-
Non-functional requirements and quality attributes such as performance and security.
-
Mechanisms for achieving cloud-native capabilities.
Although the design model is described using Scala programs, at the design stage it is limited to foundation description, with final realization through Scala programming in the implementation phase.
Since Scala is used to describe the design model, the boundary between design and implementation can be subtle. In this approach, design is considered complete when BDD/TDD-based specification descriptions (test programs) compile, and implementation is the work of Scala programming to make all test programs pass.
Domain Mechanics
In the analysis model, the focus is on the structure and behavior of the domain model itself, whereas in the design model, it is necessary to consider the mechanisms for performing concrete operations on the target platform.
In SimpleModeling, the mechanisms for operating the domain model are called Domain Mechanics, and they are designed separately from the domain model itself.
Representative Domain Mechanics objects:
-
Factory: Manages the creation of objects
-
Repository: Persists and retrieves objects and aggregates
-
Aggregate: A set of domain objects with a consistency boundary
Analysis Model Up/Down
In SimpleModeling, the conceptual, analysis, and design models are not regarded as being simply transformed from "top to bottom."
Each model is handled independently and in parallel according to its purpose, while maintaining consistency and evolving concurrently.
At the center is the analysis model described in the literate model using CML (Cozy Modeling Language).
Starting from this analysis model, generation and supplementation are carried out in the following directions:
-
Upper (Abstraction): Generate the conceptual model (for business stakeholders)
-
Lower (Concretization): Generate the design model (for developers and implementation)
Analysis Model
The core of Analysis Model Up/Down is the analysis model.
From the analysis model described in CML, Cozy generates the conceptual and design models.
-
Share specifications with stakeholders such as on-site customers and domain experts
-
Serve as an adjustment point to balance business requirements and technical requirements
Conceptual Model
The conceptual model is automatically or semi-automatically generated from the analysis model described in CML and is used to share the overall business picture with stakeholders.
-
Share objectives, values, and constraints with business owners
-
Function as a navigation model that clarifies the meaning of terms and structures
Design Model
The design model is built primarily around code automatically generated by Cozy or AI.
Some design model information can also be described in CML, allowing it to be added as design model information to the analysis model’s CML.
Since the basic foundation is generated by Cozy, the task is to verify the validity of that foundation and add concrete details.