Коллеги, если проголосуете - буду рад, но сторизы не обещаю 🙂)

Еще один интересный тезис из книги, где evolutionary architecture сравнивается в селекцией породистых собак:

💬 While software architects are interested in exploring evolutionary architectures, we aren’t attempting to model biological evolution. Theoretically, we could build an architecture that randomly changed one of its bits (mutation) and redeployed itself. After a few million years, we would likely have a very interesting architecture. However, we don’t have millions of years to wait.

We want our architecture to evolve in a guided way, so we place constraints on different aspects of the architecture to reign in undesirable evolutionary directions. A good example is dog breeding: By selecting the characteristics we want, we can create a vast number of different shaped canines in a relatively short amount of time.

Что интересно в этой фразе? А интересно здесь то, что в кинологии:

💬 По мере возникновения исторических изменений в породе в стандарт могут вносится корректировки.

💬 Стандарт периодически пересматривают и изменяют, что обеспечивает прогресс породы

-- Википедия.

Прошу простить за адресацию к Википедии - всё-таки я не кинолог и не зоотехник 🙂) Последняя цитата взята из http://www.kgau.ru/distance/zif_03/razvedenie-110401/07_01.html - вроде заслуживает доверия.

Ключевой момент - изменения в стандарт вносятся не только по мере выявления желаемых свойств породы, но и по мере достижения самих изменений в породе.

В общем, суть та же, о которой говорилось здесь. Архитектор выступает в роли автора стандарта породы, а разработчик - в роли заводчика, который выбирает (путём сравнения) для репродукции такой экземпляр породы из всех возможных, который наилучшим образом соответствует стандарту.

Можно добавить, что стандарт породы содержит, кроме самого требования, еще и допустимое отклонение (допустимый диапазон изменчивости).

Вебининар по EventSoursing.

Коллеги, помните, я писал про этого парня @schetinnikov ? В этот четверг он проведет вебинар про Event Sourcing, и расскажет, как внедряли его на практике, какие были подводные камни, какой результат был достигнут. Подробности здесь:
https://news.1rj.ru/str/ru_arc/278

P.S.: прошу поддержать репостом

P.S.S.: исправил ссылку на событие.

Коллеги, что думаете об этом утверждении Дональда Трампа?

Статья про доменную модель, о которой я говорил, опубликована:
https://dckms.github.io/system-architecture/stanislav.bolsun/it/ddd/domain-model/domain-model-definition.html

Глубоко признателен @StanislavBolsun за авторство и за проделанный труд.

Есть идеи организовать по материалам статьи вебинар с автором.

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

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

Вторая часть серии, на мой взгляд, оказалась заметно слабее первой. (Может тема такая). Тем не менее, я думаю, что оставшиеся две заметки:
- DDD Aggregates: Consistency Boundary
- DDD Aggregates: Optimistic Concurrency
реабилитируют серию. Рекомендую их посмотреть

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

В каноническом определении 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)

См. также...

В официальном твиттер-аккаунте The Open Group, посвященном ArchiMate, позавчера снова появилась ссылка на кликабельный Language Notation Guide

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