Создана группа для доработки статьи. Это хорошее событие, поскольку оно зарождает традицию научных дискуссий - давняя мечта одного моего давнего товарища.

Если кто-то хочет внести свой вклад, пишите мне в личку @emacsway - я добавлю в группу.

Хочу поделиться выводами, возникшими в результате обсуждения статьи.

В каноническом определении DDD я недооценивал третий пункт: "Speak a ubiquitous language within an explicitly bounded context." За этой скромной фразой не видно всей глубины её смысла.

Текст под картинкой гласит: "With a UBIQUITOUS LANGUAGE, conversations among developers, discussions among domain experts, and expressions in the code itself are all based on the same language, derived from a shared domain model."

Подчеркну: "shared domain model".

А также: "The model is the backbone of a language used by all team members. Because of the binding of model and implementation, developers can talk about the program in this language. They can communicate with domain experts without translation. And because the language is based on the model, our natural linguistic abilities can be turned to refining the model itself."
-- DDD by Eric Evans

Продолжение...

Я продолжу.

В процессе обсуждения возник аргумент, что mental model, служащая для описания и выравнивания понимания того, что происходит в problem space, все-таки отличается от модели решения (solution space).

Свидетельство этого можно обнаружить, например, в спецификации ArchiMate: "Layers – the three levels at which an enterprise can be modeled in ArchiMate – Business, Application, and Technology".

DDD отличается тем, что Application Model разделяет (shared) Business Model, что и образует ubiquitous language.

Обратите внимание, Event Stroming начинается с исследования предметной области (Big Picture), а заканчивается проектированием системы (Software Design или Modeling software systems) на той же самой диаграмме, которая после реализации практически 1:1 будет отражать структуру кода.

Можно даже не создавать никакой отдельной диаграммы (как и модели) для Application Layer:

💬 Work on the existing model. Modeling processes, injecting new concepts on top of the existing artifact works well in small groups scenario and/or when you have the possibility of a full-day (or more than one day) workshop.
-- Introducing EventStorming by Alberto Brandolini

💬 Big Picture workshop tried hard not to focus but to embrace the whole complexity and maximize learning. Now the starting point is different: * we can assume we have a shared better understanding of the underlying domain here the focus is on implementing software features that are solving a specific problem.
...
Here we are trying to find one or more solutions to a problem worth solving. This means that the workshop isn’t over until we have something that looks like a robust candidate solution.
...
the big picture was a model of our current level of understanding, by digging deeper into key interaction we are already making it obsolete.
-- Introducing EventStorming by Alberto Brandolini

💬 Design a portion of the software system to reflect the domain model in a very literal way, so that mapping is obvious. Revisit the model and modify it to be implemented more naturally in software, even as you seek to make it reflect deeper insight into the domain. Demand a single model that serves both purposes well, in addition to supporting a fluent ubiquitous language.
-- DDD Reference by Eric Evans

Вот что скрывается за фразой ubiquitous language. Это, наверное, наиболее существенный отличительный признак DDD.

Продолжение...

Что такое модель по SEBoK:
🔷 https://sebokwiki.org/wiki/Model_(glossary)

🔷 https://sebokwiki.org/wiki/What_is_a_Model%3F

🔷 https://sebokwiki.org/wiki/Types_of_Models

🔷 https://sebokwiki.org/wiki/Why_Model%3F

Что такое концептуальная модель:

🔷 https://sebokwiki.org/wiki/System_Modeling_Concepts#Conceptual_Model

🔷 https://sebokwiki.org/wiki/Concept_(glossary)

См. также...

When you are just getting started in your software modeling efforts, your Bounded Context is
somewhat conceptual. You could think of it as part of your problem space. However, as your model
starts to take on deeper meaning and clarity, your Bounded Context will quickly transition to your
solution space , with your software model being reflected as project source code. (The problem
space and solution space are better explained in the box.) Remember that a Bounded Context is
where a model is implemented, and you will have separate software artifacts for each Bounded
Context.

и

The best Ubiquitous Language will be developed by a collaborative feedback loop
that drives out the combined mental model of the team. Open conversation, exploration, and
challenges to your current knowledge base result in deeper insights about the Core Domain.

интересная мысль у Вернона в distilling DDD

В этом тексте Vaughn Vernon поясняет, почему Domain Model по своему названию относится к области проблемы, а на самом деле - к области решения. В общем, он подтверждает правильность моих выводов.

В DDD немало таких логических противоречий, что затрудняет его освоение, но не уменьшает его практической ценности. Некоторые из них были описаны в этой статье.

Как вы считаете, какие последствия наступают, если команда не понимает, что такое модель, как её формировать и определять её границы? Нужна ли вообще вся эта "академичность"? Живут же как-то без этого... Напишите своё мнение.

💬 The traditional software development lifecycle implies the following translations:

- Domain knowledge into an analysis model
- Analysis model into requirements
- Requirements into system design
- System design into source code

Instead of continuously translating domain knowledge, domain-driven design calls for cultivating a single language for describing the business domain: the ubiquitous language.

...

Modeling the Business Domain

When cultivating a ubiquitous language, we are effectively building a model of the business domain. The model is supposed to capture the domain experts’ mental models—their thought processes about how the business works to implement its function. The model has to reflect the involved business entities and their behavior, cause and effect relationships, and invariants.

The ubiquitous language we use is not supposed to cover every possible detail of the domain. That would be equivalent to making every stakeholder a domain expert. Instead, the model is supposed to include just enough aspects of the business domain to make it possible to implement the required system; that is, to address the specific problem the software is intended to solve. In the following chapters, you will see how the ubiquitous language can drive low-level design and implementation decisions.

-- Learning DDD by Vladik Khononov

В 2022 году я думал, как хорошо, что в РФ есть такая компания как Яндекс, которая обеспечивает технологическую независимость страны. Как я тогда ошибался. Нет ничего хуже монополии в условиях безальтернативности, которая приводит к полной зависимости от прихоти монополиста. Про цены на Яндекс.Такси, который выкупил почти всех своих ключевых конкурентов, на сегодняшний день не написал только ленивый. Яндекс.Такси вверг меня в середину 90-х - бордюрщики и заказы по телефону местячкового такси по спальному району Москвы вновь стали обычной практикой в то время, как человечество научилось управлять транспортным средством силой мысли. Прогресс корпорации Яндекс налицо. Но еще больше меня поразило не это.

Никогда не думал, что в наше время поставщик услуг может без согласия клиента в прямом смысле залезть к нему в карман, самовольно по своей прихоти установить любой тарифный план и списать любую сумму денег без права на апелляцию. Но еще удивительней то, что отключить навязанный тариф технически невозможно - кнопка отписки просто неактивна. Так же технически невозможно открепить карту или отписаться от подписки на Плюс полностью - такая возможность просто отсутствует в пользовательском интерфейсе. Попытки отписаться от навязанного тарифа и вернуть свой тариф (который актуальный, не архивный) обернулись тем, что теперь активно аж два навязанных тарифа, причем, второй из них - по промокоду, который никто не вводил. И все это по цене, по которой я на Wink получаю в три раза больше (шесть кинотеатров одновременно вместо двух).

Первой под снос пошла Яндекс.Клавиатура. За вчерашний день половина моих поездок была на Сити.Мобил и на бордюрщиках. Да, приходится дольше ждать и не всегда удается вообще дождаться, но теперь это вопрос принципа - в рыночной экономике просто обязана быть здоровая конкуренция, которую иногда нужно поддержать, чтоб никто не зажрался. Постепенно исключаю Яндекс из своей жизни. Petal.Maps вместо Яндекс.Карт. Акции Яндекса - только в шорт. И я счастлив, что хотя бы бордюрщики бросили вызов конкуренции "самой высокотехнологичной компании страны".

Извините за оффтоп.

Что такое оценка? Как её выразить? Очень хорошая краткая статья:
"How to Read Lead Time Distribution" by Mauvisoft Team

💬 Simplicity is the ultimate sophistication.
-- Leonardo da Vinci

Не смог не купить 🙂

очень подробно описано все в книге - Domain Modeling Made Functional
(про ДДД)

Understanding the problem doesn’t mean that building a solution is easy. The solution can’t possibly represent all the information in the original domain, nor would we want it to. We should only capture the information that is rele- vant to solving a particular problem. Everything else is irrelevant.
We therefore need to create a distinction between a “problem space” and a “solution space,” and they must be treated as two different things. To build the solution we will create a model of the problem domain, extracting only the aspects of the domain that are relevant and then re-creating them in our solution space as shown in the figure on page 17.

---

That means that things in our design must represent real things in the domain expert’s mental model. That is, if the domain expert calls something an “order,” then we should have something called an Order in the code that corresponds to it and that behaves the same way.
And conversely, we should not have things in our design that do not represent something in the domain expert’s model. That means no terms like OrderFactory, OrderManager, OrderHelper, and so forth. A domain expert wouldn’t know what you meant by these words. Of course, some technical terms will have to occur in the codebase, but you should avoid exposing them as part of the design.
The set of concepts and vocabulary that is shared between everyone on the team is called the Ubiquitous Language—the “everywhere language.” This is the language that defines the shared mental model for the business domain. And, as its name implies, this language should used everywhere in the project, not just in the requirements but in the design and, most importantly, in the source code.

In the first chapter, when we were talking about the importance of a shared mental model, we emphasized that the code must also reflect this shared model and that a developer should not have to do lossy translations between the domain model and the source code.