Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| arch:evolutionofdomainmodelingapproachesandtools [2021/10/17 11:59] – Sum libatalova | arch:evolutionofdomainmodelingapproachesandtools [2026/08/29 07:59] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 4: | Line 4: | ||
| ==== Introduction ==== | ==== Introduction ==== | ||
| - | |||
| At different points at time, people had different attitudes towards software development. First, it was pure engineering, | At different points at time, people had different attitudes towards software development. First, it was pure engineering, | ||
| Line 11: | Line 10: | ||
| 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. | 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. | ||
| + | |||
| ==== Domain modeling ==== | ==== Domain modeling ==== | ||
| - | 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, | + | 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, |
| - **Transaction Script**. It organizes business logic by procedures where each procedure handles a single request from the presentation. | - **Transaction Script**. It organizes business logic by procedures where each procedure handles a single request from the presentation. | ||
| - **Table Module**. A single instance that handles the business logic for all rows in a database table or view. | - **Table Module**. A single instance that handles the business logic for all rows in a database table or view. | ||
| - **Domain Model**. An object model of the domain that incorporates both behavior and data. | - **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. | 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 " | ||
| - | Eric Evans' | + | 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. |
| - | - **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. | + | |
| + | Eric Evans' | ||
| + | |||
| + | - **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. | ||
| - **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. | - **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. | ||
| - **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. | - **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. 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: | + | 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: |
| - Requests. They return a result, do not change the state of the system, and have no side effects. | - Requests. They return a result, do not change the state of the system, and have no side effects. | ||
| - Teams. Change the state of the system. | - Teams. Change the state of the system. | ||
| + | |||
| CQRS is suited to complex domains, the kind that also benefits from Domain-Driven Design. Particularly, | CQRS is suited to complex domains, the kind that also benefits from Domain-Driven Design. Particularly, | ||
| ==== Tools and frameworks ==== | ==== Tools and frameworks ==== | ||
| - | |||
| Although domain-driven design is not tied to any particular tool or framework, some well-known examples include: | 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 | + | |
| - | • CubicWeb - an open-source Semantic Web Framework | + | * Actifsource - domain specific modeling workbench, a plug-in for Eclipse. It enables software development combining DDD with model-driven engineering and code generation. |
| - | • OpenMDX - an open-source, | + | |
| - | • 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. | + | |
| + | | ||
| + | |||
| + | ==== Conclusion ==== | ||
| + | |||
| + | 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. | ||
| ==== References ==== | ==== References ==== | ||
| - | | + | |
| - | - Edward Yourdon, | + | |
| - | - Gerald Weinberg, | + | - Edward Yourdon, |
| - | - Martin Fowler, | + | - Gerald Weinberg, |
| + | - Martin Fowler, | ||
| - Martin Fowler, “Patterns of Enterprise Application Architecture”. November 5, 2002 | - Martin Fowler, “Patterns of Enterprise Application Architecture”. November 5, 2002 | ||
| - | - Vaughn Vernon, | + | - Vaughn Vernon, |
| + | - “What is the CQRS pattern?” Microsoft Ignite. [[https:// | ||