by Liana Batalova, libatalova@edu.hse.ru

At different points at time, people had different attitudes towards software development. First, it was pure engineering, the work with the machines, hardware was the priority. But then over time the software development industry started actively grow and move forward. It became hard to think in the terms of code and hardware, thus such abstractions like classes, structures, and OOP came along. Later with the growth of the IT industries new levels of abstractions were there to come. People started realizing the importance of sharing areas of responsibility, the high-level system organization as it significantly influences the speed of development and the quality of the final product. In this essay the growth of domain modeling approaches and tools will be discussed.

During a long period of time the focus was mainly on the software and coding itself. However, in some of the earliest textbooks on how to do software engineering like “Modern Structured Analysis” by Edward Yourdon and “An Introduction to General Systems Thinking” by Gerald Weinberg it was written that the real focus should be on understanding the domain, its modeling. The main idea primary pointed that it’s significant to restructure the relationship between IT and the business by minimum defining the common vocabulary. This at least would allow to talk about the same set of objects, how they behave, what they do and in which way they interact. Thus, domain-driven design came along in recognition of the fact that the initial focus was wrong. The focus exclusively on the machine was not productive and helpful, the key problem lies in analyzing and comprehending the structure of that part of the world in which the designer must figure it out.

The idea that software systems should be well-designed has been around for a long time. Having adopted many ideas from James J. Odell, who developed such concepts like data modeling, information engineering, and object-oriented analysis, Martin Fowler, a software engineer, and an independent consultant, published his book “Patterns of Enterprise Application Architecture” in 2002 [4]. This book is still a classic in the development of enterprise applications. Martin Fowler provides three templates for organizing business logic in a project, these are:

1. Transaction Script. It organizes business logic by procedures where each procedure handles a single request from the presentation.
2. Table Module. A single instance that handles the business logic for all rows in a database table or view.
3. Domain Model. An object model of the domain that incorporates both behavior and data.

The domain model differs from the others is that it builds a full-fledged model of the subject area that reflects the real world. The model consists of entities with behavior that interact with other entities. The relationships between them are defined explicitly. Each instance of an entity can be identified and distinguished from others, it encapsulates the state of the object and its behavior. This means that it’s impossible in any way outwardly bring it to an inconsistent state without informing the object about how to change its state or force it to behave somehow the way it should not behave. This template is the most successful for use in complex information systems because it structures the domain in the best way and contributes to our understanding.

As a development of the Martin Flower’s Domain Model, Eric Evans' book “Domain-Driven Design: Tackling Complexity in the Heart of Software” was published in 2003. Eric Evans was the one who introduced the “domain-driven design” name, it is described through a catalogue of patterns. This book contains not only a description of the “domain model” template, but also a certain set of approaches that show us how to work with such a set and in the end build the domain model.

Eric Evans's great contribution to this, through his book, was developing a vocabulary to talk about this approach, identifying key conceptual elements that went beyond the various modeling notations that dominated the discussion at the time. He highlighted the following pillars of DDD [1]:

1. Crunching Knowledge Domain-Driven Design is about knowledge rework. The existing knowledge about the subject area needs to be analyzed, from which it is necessary to highlight the actual subject area.
2. Ubiquitous language. It is necessary to designate a ubiquitous language. Any model provides some terminology that forms its own language, and with which you can work, speak it, write.
3. Model Driven Design is the most technical part of DDD, which means that the directly invented model of the domain is mapped into the code, and we can only find it there, and not anywhere else.

The CQRS has appeared relatively recently. CQRS is an architecture pattern that separates models for reading and writing data [7]. The related concept of Command and Query Separation (CQS) was first introduced by Bertrand Meyer in his book “Object-Oriented Software Construction” in 1994. The basic idea is that you can divide the operations of the system into two clear categories:

1. Requests. They return a result, do not change the state of the system, and have no side effects.
2. Teams. Change the state of the system.

CQRS is suited to complex domains, the kind that also benefits from Domain-Driven Design. Particularly, CQRS should only be used on specific parts of a system (a Bounded Context in DDD lingo) and not on the system itself. In this way of thinking, each bounded context needs its own decisions about how it should be modeled.

Although domain-driven design is not tied to any particular tool or framework, some well-known examples include:

• Actifsource - domain specific modeling workbench, a plug-in for Eclipse. It enables software development combining DDD with model-driven engineering and code generation.
• CubicWeb - an open-source Semantic Web Framework completely driven by a data model.
• OpenMDX - an open-source, based on Java, MDA Framework with support for Java SE, Java EE and .NET.
• Restful Objects - a Restful API standard for the Domain Object Model (where domain objects can represent entities, view models or services). Two open-source platforms (one for Java, one for .NET) can automatically create Restful Objects APIs from a domain model using reflection.

Domain modeling appeared recently, although it hasn’t reached full potential, I believe that the popularity of it is yet to come. Codebase expands each day and there’s no silver bullet approach that would suite everyone, domain-driven design is likely to become the one.

1. Eric Evans, “Domain-Driven Design: Tackling Complexity in the Heart of Software”, 2003. p. 23-71 https://github.com/gg-daddy/ebooks/blob/master/Eric%20Evans%202003%20-%20Domain-Driven%20Design%20-%20Tackling%20Complexity%20in%20the%20Heart%20of%20Software.pdf
2. Edward Yourdon, “Modern Structured Analysis”, 1st edition (January 1, 1991)
3. Gerald Weinberg, “An Introduction to General Systems Thinking”, February 12, 1975
4. Martin Fowler, “DomainDrivenDesign”, April 12, 2020. https://martinfowler.com/bliki/DomainDrivenDesign.html
5. Martin Fowler, “Patterns of Enterprise Application Architecture”. November 5, 2002
6. Vaughn Vernon, “Implementing Domain-Driven Design”. April 24, 2015
7. “What is the CQRS pattern?” Microsoft Ignite. https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs