Written by Egor Timonin (estimonin@edu.hse.ru)

Domain modeling translates real-world systems into models that possess important properties through entities, their communication and behaviours. Structured and data modeling methods enhance properties of the domain model and improve clarity and share understanding of the proposed system among stakeholders and developers.

Structured methods introduced by Edsger W. Dijkstra [1] through structured programming with aim to decompose complex systems into smaller parts. After Data Flow Diagrams (DFD) [2] and Entity-Relationship Diagram (ERD) [3] appeared as continuation of development of structured methods. Whereas modern data modeling methods were developed from hierarchical and network models [4] to ensure that system has optimized in terms of perfomance, integrity and scalability scheme.

Applying structured and data modeling methods plays significant part of creating modern software systems, such as microservice oriented systems and distrubuted systems. These methods are helping to clearly define context boundaries between components and their interactions making these systems scalable and maintainable. Applying these methods could decrease coupling between components enabling system flexibility.

Structured methods are techniques that help decompose the system into smaller parts in terms of communication between components and data transformations. A “good” model has to incorporate significant data into the model and use stepwise approach to construct model from validated submodels [5]. Structured methods used to model the real-world systems that typically do not fit into computational models. There are various structured methods exists, but the commonly used methods are:

• Data Flow Diagrams (DFD) — method represent how data moves through the entire system and how it can be transformed at different level of decomposition, from high level view of the system (Level 0) to more detailed views (Level 1, 2) [6], each level of decomposition represent how the system working by different system components. This method is useful to visualise interaction how system reacts on different inputs and how data changes in the system. This representation can help to detect bottlenecks of the system.

• Entity-Relationship Diagram (ERD) — method illustrate how entities relate to each other in the system and convey their dependencies, making this method useful for designing database ensuring integrity of the data.

• State Diagrams — method that represent the system in terms of states that entities could have, inputs and events that trigger state changes. This method could be useful for exploring the system how it should react on different events, inputs, helping to show behaviour of the system and conditions which trigger state changes.

• Control Flow Diagram — method represent system as sequence of actions that have to be performed. This method is useful when we need to describe control logic systems (such as algorithms) using conditions to show how data have to be processed.

As we decided with the system behaviour and data transformations, we can use data modeling methods to refine data allocation in the system.

Data modeling methods represent how data is stored in the system and show how data entities connected with each other. Data models play a significant role in constructing the system, because they allow the creation of an accurate and reliable structure for data storage, improve data integrity and enhance flexibility and maintenance of the entire system [7]. Numerous data modeling methods can be applied for creating data models, each of them is applicable depending on the specific properties that system need to possess:

• Hierarchical Model — This method can be applicable for data with clear parent-child relations, but it is mostly replaced by relational models, because of lack of the flexibility that is important for modern systems.

• Object-oriented Model — represent data as real-world object entities with data and behaviour encapsulation, making this method useful for object-oriented programming (OOP) languages like C++, C# or Java.

• Entity-Relationship (ER) Model — method expresses relations between data entities and helps identify key entities that are vital for the system making this method useful to reflect real-world system.

• Relational Model — method that separates data entities into tables and allows to create explicit relations between entities using primary and foreign keys. This model is the base of modern systems, because most of them using SQL databases.

• Dimensional model — method that helps to create model for data warehouses using fact and dimensions tables for representing data. This model stores factual information and measures that could be helpful for working with large amounts of data.

Unlike relational SQL databases, which uses structured tables, modern systems more often use NoSQL databases, because they allow to store large amount of unstructured data, that make it flexible, but it still major to choose the right data models for the system ensuring system scalability and perfomance.

Using both types of modeling we can create domain model that will reflect the real-world system precisely.

Domain modeling is the process of representing the system in real-world using entities and relations between them [8] in terms that could be more clearer for software engineers, stakeholders and other actors of software development process.

The domain model contains data and the behaviour, representing the future system. Structured methods provide the view of the system behaviour at any level of the system decomposition, whereas data modeling methods assist in constructing data schema for the proposed system. The collaboration of these approaches of working with the system ensures a comprehensive representation of the system that satisfies business and technical requirements.

The first step in domain modeling is to define the problem that the system is going to solve. A critical aspect of this process is defining bounded contexts [9] for the system, because it helps to understand possible system responsibilities and allocate them between entities.

For example, in the system that handle work between seller and client, we must define responsibilities of seller and client systems. The seller system is responsible for creation and deletion products and sales, while client system handles purchases and returns. Also, we need to define how the seller and client systems interact.

After defining the bounded contexts for proposed system, we can create domain model to represent top-level structure of the system. For example, we can use structured method DFD (Level 0) to show how the system operates and how data moves through the system.

Figure 1: Level 0 system diagram

The domain model is developing (figure 1), so it may become clear that direct communication between sellers and client system is not sufficient, because sellers are not responsible for purchases and returns, so we have to create another system that handle and store information used for interaction between seller and client systems.

The next step in domain modeling is to continue of top-level schema system decomposition into specific subsystems, resolving responsibilites and behaviours that every part must possess. This process of decomposition should be provided using shared understanding among all team members, which improves definition of the entities and their behaviours.

For example, if the client system provides functionality to purchase or return product, we must support connection between product and client, so there need parts that are responsible for purchasing and returning products. These interactions must be clearly defined. Using an example of purchasing product by client.

Figure 2: Level 1 system diagram

As we decompose the system (figure 2), new entities with their behaviours appeared. Owing to fact that sellers cannot have unlimitied products stocks, so it is required to have the stocks system that will be responsible for stocks and will track available products for the seller. Also client can not interact with the product system directly, because we need to track their purchases, so the ordering system appeared as shown Level 1 DFD on the picture.

After further decomposition the system we may reach a level of decomposition that will require to create data model of the system to better understand the specific of the future system. This model will also affect our entire system. For example, we can design the system where stocks used as part of the product to show to the client available items that can be purchased, but it would create redundancy issues, because stocks not always required when we request product information. We need to research usage of product information to decide how to store this information.

Domain modeling can apply different methods to define the system, but all of them serve to improve understanding of the future system, making it possible to create efficient and flexible software solutions. Also models used as bridge between technical specialists and stakeholders using understandable for both groups “language” for the communication.

New systems become more complex, actual systems getting more complicated, which increase the role of domain modeling in designing systems, because the price of making a mistake also increased. With using these methods we can ensure that systems would be flexible, scalable and performing.

1. Edsger W. Dijkstra, “Go-to statement considered harmful”, 1968.
2. Yourdon, Edward; Constantine, Larry L, “Structured Design”, 1975.
3. Peter Chen, “The Entity-Relationship Model - Toward a Unified View of Data”, 1976.
4. Cornelius T. Leondes, “Database and Data Communication Network Systems: Techniques and Applications”, 2002, p. 7.
5. Arthur M. Geoffrion, “An Introduction to Structured Modeling”, 1987, p. 550.
6. Steve Easterbrook, “Structured Modeling Methods”, 2001, p. 5.
7. Rupal Sharma, “What is Data Modeling: Tools and Techniques Involved in the Process”, 2024.
8. Norberto Rodríguez (Norbs), “Domain Modeling: What you need to know before coding”, 2021.
9. Eric Evans, “Domain-Driven Design: Tackling Complexity in the Heart of Software”, 2003, p. 298.