diff --git a/.github/workflows/pull_request.yml b/.github/workflows/pull_request.yml index f64d8e8e..9ecbfcc3 100644 --- a/.github/workflows/pull_request.yml +++ b/.github/workflows/pull_request.yml @@ -8,11 +8,11 @@ jobs: runs-on: ubuntu-22.04 steps: - - uses: actions/checkout@v1 + - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Set up Python - uses: actions/setup-python@v1 + uses: actions/setup-python@v5 with: python-version: 3.10.13 - name: Install dependencies diff --git a/.github/workflows/simple.yml b/.github/workflows/simple.yml index 55f6a253..adae0ab1 100644 --- a/.github/workflows/simple.yml +++ b/.github/workflows/simple.yml @@ -10,11 +10,11 @@ jobs: runs-on: ubuntu-22.04 steps: - - uses: actions/checkout@v1 + - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Set up Python - uses: actions/setup-python@v1 + uses: actions/setup-python@v5 with: python-version: 3.10.13 - name: Install dependencies diff --git a/README.rst b/README.rst index b2193baa..d869b122 100644 --- a/README.rst +++ b/README.rst @@ -212,7 +212,7 @@ Sphinx-doc предоставляет и тегирование/индексир #. Если не установлен Python, то `установите его `__. #. Установите зависимости. Для этого, из корневой директории проекта выполните команду: ``pip install -r requirements.freeze.txt`` #. Отредактируйте файл conf.py, подробности смотрите в `документации `__. -#. Произведите сборку: ``make html`` или ``sphinx-build -D language=ru -b html . _build`` или ``docker build -t sphinx_image . && docker run -v $(pwd):/sphinxtechnicalwriting sphinx_image make html`` +#. Произведите сборку: ``make html`` или ``sphinx-build -D language=ru -b html . _build`` или ``docker build -t sphinx_image . && docker run -v $(pwd):/sphinxtechnicalwriting sphinx_image sphinx-build -D language=ru -b html . _build`` #. Локальный запуск: ``python -m http.server`` #. Подробнее `здесь `__. diff --git a/stanislav.bolsun/it/ddd/domain-model/_media/actor_perspective.png b/stanislav.bolsun/it/ddd/domain-model/_media/actor_perspective.png new file mode 100644 index 00000000..204c71b8 Binary files /dev/null and b/stanislav.bolsun/it/ddd/domain-model/_media/actor_perspective.png differ diff --git a/stanislav.bolsun/it/ddd/domain-model/_media/ddd_model_and_reality.png b/stanislav.bolsun/it/ddd/domain-model/_media/ddd_model_and_reality.png new file mode 100644 index 00000000..09a0c45b Binary files /dev/null and b/stanislav.bolsun/it/ddd/domain-model/_media/ddd_model_and_reality.png differ diff --git a/stanislav.bolsun/it/ddd/domain-model/_media/domain_model_uml.jpg b/stanislav.bolsun/it/ddd/domain-model/_media/domain_model_uml.jpg new file mode 100644 index 00000000..5ebbffe1 Binary files /dev/null and b/stanislav.bolsun/it/ddd/domain-model/_media/domain_model_uml.jpg differ diff --git a/stanislav.bolsun/it/ddd/domain-model/_media/model_of_earth_processes.png b/stanislav.bolsun/it/ddd/domain-model/_media/model_of_earth_processes.png deleted file mode 100644 index 3ab078bf..00000000 Binary files a/stanislav.bolsun/it/ddd/domain-model/_media/model_of_earth_processes.png and /dev/null differ diff --git a/stanislav.bolsun/it/ddd/domain-model/_media/model_perspectives.jpeg b/stanislav.bolsun/it/ddd/domain-model/_media/model_perspectives.jpeg new file mode 100644 index 00000000..bedb769f Binary files /dev/null and b/stanislav.bolsun/it/ddd/domain-model/_media/model_perspectives.jpeg differ diff --git a/stanislav.bolsun/it/ddd/domain-model/_media/real-model-impl.jpg b/stanislav.bolsun/it/ddd/domain-model/_media/real-model-impl.jpg deleted file mode 100644 index 024f44ea..00000000 Binary files a/stanislav.bolsun/it/ddd/domain-model/_media/real-model-impl.jpg and /dev/null differ diff --git a/stanislav.bolsun/it/ddd/domain-model/_media/shared_mental_model.jpg b/stanislav.bolsun/it/ddd/domain-model/_media/shared_mental_model.jpg new file mode 100644 index 00000000..c632316f Binary files /dev/null and b/stanislav.bolsun/it/ddd/domain-model/_media/shared_mental_model.jpg differ diff --git a/stanislav.bolsun/it/ddd/domain-model/domain-model-definition.rst b/stanislav.bolsun/it/ddd/domain-model/domain-model-definition.rst index 2373cf12..372d48d6 100644 --- a/stanislav.bolsun/it/ddd/domain-model/domain-model-definition.rst +++ b/stanislav.bolsun/it/ddd/domain-model/domain-model-definition.rst @@ -10,17 +10,27 @@ Domain Model Definition .. sectionauthor:: Stanislav Bolsun -Как показывает моя практика, понимание таких фундаментальных основ как доменная модель, границы доменной модели (ограниченный контекст), могут заметно повысить эффективность (скорость) команды разработки. +Как показывает моя практика, понимание таких фундаментальных основ как доменная модель, границы доменной модели (ограниченный контекст), заметно могут повысить эффективность (скорость) команд разработки. .. contents:: Содержание + + Доменная модель =============== -Начнем с канонического определения модели по Эвансу: +Прежде чем перейти к тому, что такое доменная модель нам желательно разобраться еще с несколькими понятиями, которые описываются далее. + + + +Что такое модель +---------------- + +Рассмотрим понятие модели из различных источников, начиная с модели по Эвансу: 💬 "every model represents some aspect of reality or an idea that is of interest. - A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail..." + A model is a simplification. + It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail..." -- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans @@ -30,25 +40,174 @@ Domain Model Definition -- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans, перевод В.Л. Бродового -Каждая модель имеет свой контекст применимости, без контекста применимости мы не сможем создать модель, так как не знаем какую проблему решаем (то есть какие свойства и поведение нужны для решения конкретной проблемы). +.. -.. figure:: _media/model_of_earth_processes.png - :alt: Model of Earth processes + 💬 "So, models represent some artifact of the real world, but with a narrow purpose. + How much space the building will occupy and how high the whole complex will be, for example, + are often just enough for a rough model, during the first review stage of the building project. + Models do not intend to replicate real life. Instead, they represent some particular aspects of real life at a certain level of detail, + depending on the purpose of the model..." + + -- "Hands-On Domain-Driven Design with .NET Core: Tackling complexity in the heart of software by putting DDD principles into practice" by Alexey Zimarev + +.. + + 💬 Model (glossary) + + (1) A physical, mathematical, or otherwise logical representation of a system, entity, phenomenon, or process. (DoD 1998) + + (2) A representation of one or more concepts that may be realized in the physical world. (Friedenthal, Moore, Steiner 2009) + + (3) A simplified representation of a system at some particular point in time or space intended to promote understanding of the real system. (Bellinger 2004) + + (4) An abstraction of a system, aimed at understanding, communicating, explaining, or designing aspects of interest of that system (Dori 2002) + + (5) A selective representation of some system whose form and content are chosen based on a specific set of concerns. The model is related to the system by an explicit or implicit mapping. (Object Management Group 2010) + + -- "SEBoK Model (glossary)" https://sebokwiki.org/wiki/Model_(glossary) + +Из определений следует, что каждая модель имеет свой контекст применимости, без контекста применимости мы не можем создать модель, так как не знаем какую проблему необходимо решить (то есть не знаем, какие аспекты оригинала будут релевантны решаемой проблеме). +Контекст применимости модели выражается ограниченным контектом (DDD), который является границей модели. + +.. figure:: _media/model_perspectives.jpeg + :alt: The model's perspective matters + :align: center + :width: 85% + + Perspective matters + + -- `Источник `__ + + + +[Дополнение] Модель по Тарасенко +--------------------------------- + + 💬 "Мы уже сформулировали два определения модели. Первое: модель есть средство осуществления любой деятельности субъекта. Второе: модель есть форма существования знаний. + Можно несколько дополнить каждое из этих определений указанием на то, что модель — тоже система, со всеми описанными в главе 2 общесистемными свойствами. + Отличительная особенность моделей от других систем состоит (в дополнение к тому, что говорят два определения) в их предназначенности отображать моделируемый оригинал, заменять его в определенном отношении, т.е. содержать и представлять информацию об оригинале. + Выразим эту мысль в виде еще одного общего определения: модель есть системное отображение оригинала. + Все три определения носят очень общий, можно сказать, философский характер. Для дальнейшего нам понадобится конкретизация типов моделей и их характерных свойств. + Как мы уже знаем, уточнение описания модели можно сделать с помощью анализа и синтеза." + + -- "Прикладной системный анализ" Ф.П. Тарасенко + +.. figure:: _media/tarasenko_model.png + :alt: 'Прикладной системный анализ' Ф.П. Тарасенко, глава '3.8. Синтетический подход к понятию модели' :align: center :width: 100% -На изображении выше, мы видим модель процессов Земли, служащую для решения определенных задач. + 'Прикладной системный анализ' Ф.П. Тарасенко, глава '3.8. Синтетический подход к понятию модели' -Ограниченный контекст, являясь границей модели, определяет контекст применимости этой модели. -На это и делают акцент Эванс (см. выше), Вернон и Зимарев в определениях модели: +и следует за этим: - 💬 "So, models represent some artifact of the real world, but with a narrow purpose. - How much space the building will occupy and how high the whole complex will be, for example, - are often just enough for a rough model, during the first review stage of the building project. - Models do not intend to replicate real life. Instead, they represent some particular aspects of real life at a certain level of detail, - depending on the purpose of the model... + 💬 "Продолжая рассмотрение отношений между моделью и оригиналом, остановимся на содержании информации в модели. Оригинал и модель — разные вещи. + В оригинале есть много такого, чего нет в модели, по двум причинам: во-первых, не все из того, что известно об оригинале, понадобится включить в модель, предназначенную для достижения конкретной цели (зона А на рис. 3.13 изображает известное, но ненужное, в том числе ошибочно сочтенное ненужным и невключенное в модель); + во-вторых, в оригинале есть всегда нечто непознанное, поэтому не могущее быть включенным в модель (зона В на рис. 3.13). - Going back to Chapter 1, Why Domain-Driven Design?, if the business domain and the particular problems we have to + Зона 2 на рисунке изображает информацию об оригинале, включенную в модель. Это истинная информация, то общее, что имеется у модели и оригинала, благодаря чему модель может служить его (частным, специальным) заменителем, представителем. + Обратим внимание на зону 3. Она отображает тот факт, что у модели всегда есть собственные свойства, не имеющие никакого отношения к оригиналу, т.е. ложное содержание. + Важно подчеркнуть, что это относится к любой модели, как бы ни старался создатель модели включать в нее только истину." + + -- "Прикладной системный анализ" Ф.П. Тарасенко + + + +Концепнуальная (ментальная) модель предметной области +----------------------------------------------------- + +В каждый конкретный момент времени человек смотрит на мир через призму определенной системы понятий, и прежде чем начать формулировать какую-либо проблему, нам придется принять какую-то модель. +Для этого нам нужно прийти к единому набору понятий, терминов для описания текущей реальности (ведь в зависимости от разных точек зрения акторов (viewpoint) реальность может описываться разными системами понятий, система глазами повара будет состоять из одних элементов, и эта же система глазами бухгалтера будет состоять из других). + +Терминология: далее, под ментальной моделью понимается концептуальная модель. + +Для выражения этой мысли приведу пример из чата по дискуссии о текущей статье, где Михаила Андронов хорошо описал этот момент: + + 💬 "Пока ты призму не принял, у тебя терминов нет, чтобы проблему выразить. + Другое дело, что люди в большинстве своём не осознают что всегда через призму какой-то модели смотрят на мир. + Считают, что то, что видят - это и есть реальность. + Например, чтобы сказать, что в комнате грязно (такая у нас проблема), у тебя должны быть понятия "комната" и "мусор". + То есть ты уже смотришь на комнату как помещение с полезными и бесполезными предметами (такая модель). + А представь, что ты при этом разговариваешь с кем-то, для кого эта комната - это место, где он был молод, счастлив и где его дети выросли. + Он на неё смотрит как на копилку счастливых воспоминаний. + В его модели невозможно выразить проблему "в комнате грязно". + И так будет до тех пор, пока он свою модель не сменит на твою." + + -- "Domain Model tg group (обсуждение статьи, https://t.me/emacsway_log/1194)" - Михаил Андронов + +Чтобы задать систему понятий и терминов, можно использовать разные подходы, такие как задание определенного viewpoint актора (бухгалтер, повар, аналитик, ...), либо же применение Big Picture воркшопа из Event Storming для построения общей ментальной модели (через выравнивание доменных знаний участников). + + 💬 "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. + + ..the big picture was a model of our current level of understanding, by digging deeper into key interaction we are already making it obsolete. + + ..Gather all the key people in the same room and build together a model of the current understanding of the system" + + -- "Introducing EventStorming" by Alberto Brandolini + + +.. figure:: _media/actor_perspective.png + :alt: Actor perspective on current reality + :align: center + :width: 100% + + Например, есть у нас организация, в ней толпа народу чего-то делают. Мы можем на них посмотреть как на сотрудников - получим одну модель (должности, отделы, ответственности и т.п.). + Можем посмотреть как на массу, которую лифты перевозят - получим другую модель (занимаемая площадь, вес, частота перемещений, направления перемещений). + Можем посмотреть как на творцов, как на членов семьи, как на представителей homo sapiens. + И это все разные модели будут. + И прежде, чем мы сможем сформулировать какую-либо проблему, нам придется принять какую-то модель (концептуальную). + Этот шаг редко осознается, хотя должен. + (пример Михаила Андронова из tg чата по обсуждению текущей статьи, https://t.me/emacsway_log/1194) + +.. + + 💬 "Знание замещает в нашем мышлении объект или его составные части. Изучая какую-то реальную вещь или системное образование мы чаще всего не можем работать непосредственно с ними. Что в устной речи, что в мышлении мы оперируем назывными конструкциями, каждая из которых относится к какому-то объективному содержанию. + + Например, говоря «стол» любому представителю современной культуры мы надеемся, что он нас поймёт не двусмысленно. Но куда указывает обозначающее слово «стол», на какой объект в каждой из ситуаций? Вероятно большинство сойдётся на том, что речь идёт о конструкции, главная функция которой — удерживать вещи с помощью горизонтальной поверхности. Но при этом читатель легко может представить себе стол, стоящий на четёрых ногах, в то время как говорящий мог представлять стол с центральной и единственной ножкой. Очевидно, что такое различие составленных представлений в ряде ситуаций может привести к конфузу. + + В нашем примере при отсутствии конкретного стола в непосредственном созерцании может возникнуть коммуникационная катастрофа — потеря содержания. Чтобы этого не произошло оба участника коммуникации должны обладать общим знанием о том какими столы бывают вообще, а также потрудиться выполнить мысленно этот перебор, когда обнаружены противоречия, чтобы выявить различие объектов у участника обсуждения." + + -- "Замещение объектов знанием" (Знания - системы понятий и утверждений), https://ashapiro.ru/articles/system-episteme + + +Отражение концептуальной (ментальной) модели также можно обнаружить, например, в спецификации ArchiMate: "Layers – the three levels at which an enterprise can be modeled in ArchiMate – Business, Application, and Technology". + +.. seealso:: + + - `Types of Models `_ + + - `Concept (glossary) `_ + + - `Conceptual_Model `_ + +Дополнение: Концептуальная (ментальная) модель предметной области является частью Problem Space. + +Теперь, когда мы поняли текущую реальность с помощью концептуальной (ментальной) модели, мы в состонии найти и описать проблему в терминах этой модели, и начать искать решение и способы интеграции его в уже новую реальность (с обеспечением целостности решения). + + + +Доменная модель +--------------- + +Осознав предметную область на основе общей ментальной модели стейкхолдеров (Problem Space), мы начинаем моделировать решение (Solution Space). +Причиной проявления решения является потребность в решений некой проблемы, в контексте решения которой возникает модель предметной области. +И эта предметная модель отражает только те аспекты поведения оригинала моделирования, которые релевантны в контексте решаения этой проблемы. + + + 💬 "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." + + -- "Domain-Driven Design Distilled" by Vaughn Vernon + +Начнем также с определения доменной модели из различных источников: + + 💬 "Going back to Chapter 1, Why Domain-Driven Design?, if the business domain and the particular problems we have to solve are in our problem space, the domain model is purely in our solution space. We will be modeling our solution, and those models will be our domain models." @@ -61,18 +220,11 @@ Domain Model Definition where those objects have both data and behavior with literal and accurate business meaning. Creating a unique, carefully crafted domain model at the heart of a core, strategic application or subsystem is essential to practicing DDD. With DDD your domain models will tend to be smallish, very focused. - Using DDD, you never try to model the whole business enterprise with a single, large domain model. Phew, that’s good!"" + Using DDD, you never try to model the whole business enterprise with a single, large domain model. Phew, that’s good!" -- "Implementing Domain-Driven Design" by Vaughn Vernon - -.. figure:: _media/real-model-impl.jpg - :alt: Real object, model and implementation - :align: center - :width: 100% - -Важное уточнение: Модель - это абстракция, которая формирует реализацию, но не является реализацией, хотя реализация и может осуществлять (реализовывать) эту модель. -Модель это часть solution space. +Эта модель является абстракцией, воплощаемой в решениеи. 💬 "A domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert's head; @@ -85,17 +237,33 @@ Domain Model Definition -- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans +Как мы уже отметили, доменная модель возникает в определеном контексте решаемой проблемы (в ограниченном контексте в терминах DDD), и служит решению этой проблемы и интеграции его с другими элементами системы (другими ограниченными контекстами). +[Дополнение]: Доменная и концептуальная модели, находясь в двух разных пространствах - Problem и Soliution spaces, описываются с помощью вездесущего языка (пронизывающего оба пространства и являющегося некой мета-моделью над моделями). -А что если попытаться реализовать единственную всеобъемливающую модель предметной области? ------------------------------------------------------------------------------------------- +.. figure:: _media/domain_model_uml.jpg + :alt: Domain model UML example + :align: center + :width: 100% -Если решаемой проблемы не существует или она неизвестена, то у нас есть два возможных пути: + Domain model UML example. -1. модель не создавать вообще + -- `Источник `__ -2. создать модель на все случаи жизни, но тогда придется полностью воспроизвести объект моделирования, что не позволит эффективно решать задачи (например, осуществление навигации судна по точной копии Земли). +.. figure:: _media/ddd_model_and_reality.png + :alt: Integrating solution into new reality + :align: center + :width: 100% + + Integrating solution into new reality + + + +А что если попытаться реализовать единственную всеобъемливающую модель предметной области? +------------------------------------------------------------------------------------------ + +Если решаемой проблемы не существует или она неизвестена, то и модель под решение у нас построить не получится, но если попробовать создать модель на все случаи жизни, то тогда придется полностью воспроизвести оригинал моделирования, что не позволит эффективно решать задачи (например, осуществление навигации судна по точной копии в масштабе 1:1 планеты Земля). 💬 "Because the term domain model includes the word domain, we might get the idea that we should create a single, cohesive, all-inclusive model of an organization’s entire business domain—you know, like an enterprise model. However, when using DDD, that is not our goal. DDD places emphasis on just the opposite. The whole Domain of the organization is composed of Subdomains. @@ -111,7 +279,7 @@ Domain Model Definition -- "Implementing Domain-Driven Design" by Vaughn Vernon -В качестве иллюстрации того, что модель создается для решения конкретных задач (имеет определенный контекст применимости), рассмотрим примеры из доклада Эрика Эванса (Eric Evans — Tackling Complexity in the Heart of Software, Domain-Driven Design Europe 2016 - Brussels, January 26-29, 2016). +В качестве иллюстрации того, что модель создается для решения конкретных задач (то есть имеет определенный контекст применимости), рассмотрим примеры из доклада Эрика Эванса (Eric Evans — Tackling Complexity in the Heart of Software, Domain-Driven Design Europe 2016 - Brussels, January 26-29, 2016). 1. Карта морского ориентирования (цилиндрическая проекция Меркатора) @@ -120,8 +288,12 @@ Domain Model Definition :align: center :width: 100% + Mercator projection + + -- `Источник `__ + Такие карты используют относительное искажение размеров объектов относительно друг друга, но помогают направлять компас в сторону нужной конечной точки (направление на карте полностью совпадет со стрелкой компаса). -На этой карте Африка и Гренландия выглядят равными по площади, но в действительности, Африка в 14 раз больше Гренландии, то есть у карты есть четкое предназначение, задача для которой она нужна, и только для нее - навигация судов. +На этой карте Африка и Гренландия выглядят равными по площади, но в действительности, Африка в 14 раз больше Гренландии, то есть у карты есть четкое предназначение, задача для которой она нужна, и только для нее - и это навигация судов. 2. Картографическая проекция земного шара на поверхность многогранника (проекция Димаксион (Фуллера)) @@ -130,7 +302,11 @@ Domain Model Definition :align: center :width: 100% -Данная проекция имеет меньшие искажения относительных размеров объектов, особенно в сравнении с проекцией Меркатора, то есть, она может служить более точным инструментом определения относительных размеров объектов земли. + Fuller projection + + -- `Источник `__ + +Данная проекция имеет меньшие искажения относительных размеров объектов, особенно в сравнении с проекцией Меркатора, то есть, она может служить более точным инструментом определения относительных размеров объектов земли (но не инсрументом навигации судов). .. seealso:: @@ -141,47 +317,32 @@ Domain Model Definition `Vaughn Vernon объясняет, почему построение канонической всеобъемлющей модели предприятия и единой предметной области на основе единой модели деятельности - миф `_ -Важное дополнение: модель по Тарасенко --------------------------------------- - 💬 "Мы уже сформулировали два определения модели. Первое: модель есть средство осуществления любой деятельности субъекта. Второе: модель есть форма существования знаний. - Можно несколько дополнить каждое из этих определений указанием на то, что модель — тоже система, со всеми описанными в главе 2 общесистемными свойствами. - Отличительная особенность моделей от других систем состоит (в дополнение к тому, что говорят два определения) в их предназначенности отображать моделируемый оригинал, заменять его в определенном отношении, т.е. содержать и представлять информацию об оригинале. - Выразим эту мысль в виде еще одного общего определения: модель есть системное отображение оригинала. - Все три определения носят очень общий, можно сказать, философский характер. Для дальнейшего нам понадобится конкретизация типов моделей и их характерных свойств. - Как мы уже знаем, уточнение описания модели можно сделать с помощью анализа и синтеза." - - -- "Прикладной системный анализ" Ф.П. Тарасенко - -.. figure:: _media/tarasenko_model.png - :alt: Tarasenko model - :align: center - :width: 100% - -и следует за этим: +Концептуальная, Доменная модели, ограниченный контекст и единый язык +-------------------------------------------------------------------- - 💬 "Продолжая рассмотрение отношений между моделью и оригиналом, остановимся на содержании информации в модели. Оригинал и модель — разные вещи. - В оригинале есть много такого, чего нет в модели, по двум причинам: во-первых, не все из того, что известно об оригинале, понадобится включить в модель, предназначенную для достижения конкретной цели (зона А на рис. 3.13 изображает известное, но ненужное, в том числе ошибочно сочтенное ненужным и невключенное в модель); - во-вторых, в оригинале есть всегда нечто непознанное, поэтому не могущее быть включенным в модель (зона В на рис. 3.13). +Ограниченный контекст - это рассмотрение объекта моделирования с определенной точки зрения, с определенного ракурса решаемой проблемы (см. пример с огурцом далее). +Основным назначением ограниченного контекста является поиск баланса между простой модели и ее достаточностью для решения проблемы (и концептуальной, и доменной модели), а именно, поиск баланса между минимизацией когнитивной нагрузки и минимизации коммуникативной нагрузки. +Тут стоит отметить, что коммуникативная нагрузка выражается через coupling, а когнитивная через cohesion (в технических терминах). - Зона 2 на рисунке изображает информацию об оригинале, включенную в модель. Это истинная информация, то общее, что имеется у модели и оригинала, благодаря чему модель может служить его (частным, специальным) заменителем, представителем. - Обратим внимание на зону 3. Она отображает тот факт, что у модели всегда есть собственные свойства, не имеющие никакого отношения к оригиналу, т.е. ложное содержание. - Важно подчеркнуть, что это относится к любой модели, как бы ни старался создатель модели включать в нее только истину." - -- "Прикладной системный анализ" Ф.П. Тарасенко + 💬 "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." -Доменная модель, ограниченный контекст и единый язык ----------------------------------------------------- + -- "Domain-Driven Design Distilled" by Vaughn Vernon -Ограниченный контекст - это рассмотрение объекта моделирования с определенной точки зрения, с определенного ракурса решаемой проблемы (см. пример с огурцом далее). -Основным назначением ограниченного контекста является поиск баланса между простой модели и ее достаточностью для решения проблемы. -Количество слов используемых человеком в лексиконе ограничено, это около 6000 слов (в зависимости от языка), а количство явлений окружающего мира - безгранично. -Это и есть та самая причина того, что если один термин обозначает несколько явлений окружающего мира, либо наоборот, одно явление мы называем различными терминами, - это обозначает лингвистический конфликт. +Количество слов используемых человеком в лексиконе ограничено, а количество явлений окружающего мира безгранично. +Это и есть та самая причина по которой существуют лингвистические конфликты, то есть ситуации, когда один термин обозначает несколько явлений окружающего мира, либо наоборот, одно явление мы называем различными терминами. .. seealso:: `Википедия: Словарный запас `_ -И при поиске ограниченных контекстов мы можем ориентироваться на эти лингвистические конфликты в процессе коммуникации (эти конфликты и являются первыми маркерами/границами ограниченнных контекстов). +И как раз при поиске ограниченных контекстов мы можем ориентироваться на эти лингвистические конфликты в процессе коммуникации (эти конфликты и являются первыми маркерами/границами ограниченнных контекстов). 💬 "The Language of a team in an explicit Bounded Context expressed as a domain model adds true business value and gives us certainty that we are implementing the correct software." @@ -190,9 +351,10 @@ Domain Model Definition Если внутри своего ограниченно контекста мы встречаем языковой конфликт, то это может являться симптомом того, что мы решаем сразу несколько задач одновременно. То есть, если мы называем одно явление разными терминами, то скорее всего это явление используется в разных контекстах, и наш контекст служит нескольким целям. -Это сигнал о том, что наша модель переусложнена и при решении одной задачи мы вынуждены работать с теми деталями модели, которые нерелевантны для нас в момент рассмотрения. Это все отбирает ресурс внимания у команды и может удорожать процесс разработки для бизнеса. +Это сигнал о том, что наша модель переусложнена и при решении одной задачи мы вынуждены работать с теми деталями модели, которые нерелевантны для нас в момент рассмотрения. +Это все создает паразитную когнитивную нагрузку у команды и может удорожать процесс разработки для бизнеса. -Поэтому, внутри каждого ограниченного контекста существует строгий единый (согласованный) язык. +Поэтому, внутри каждого ограниченного контекста существует строгий единый (согласованный) язык (система понятий). Единый (согласованный) язык не просто словарь внутри компании, это подразумевает, в первую очередь, согласованный язык внутри границ применимости модели. Мы, в рамках модели, ограничены ограниченным контекстом, где каждый термин обозначает строго одно явление. @@ -205,10 +367,32 @@ Domain Model Definition В качестве примера можно привести модель обыкновенного огурца, где термин "огурец" в каждом ограниченном контексте имеет строгое и однозначное толкование (но разное): плод, ингредиент, груз ... .. figure:: _media/cucumber_BC.jpg - :alt: cucumber in diffent Bounded Contexts + :alt: Сucumber in diffent Bounded Contexts :align: center :width: 100% + Сucumber in diffent Bounded Contexts + +Как было упомянуто ранее, единый (согласованный) язык является средством выражения и концептуальной (ментальной), и доменной моделей. +Отличительной чертой DDD является то, что в нем концептуальная (ментальная) и доменная модели совмещены, что позволяет выражать функции познавания и реализации через единую модель (именно поэтому всегда в литературе говорится явно только о доменной модели). + +.. figure:: _media/shared_mental_model.jpg + :alt: What DDD is + :align: center + :width: 100% + + (What DDD is). + What if the domain experts, the development team, other stakeholders, and (most importantly) the source code itself all share the same model? + In this case, there is no translation from the domain expert's requirements to the code. + Rather, the code is designed to reflect the shared mental model directly. And that is the goal of domain-driven design. + + +.. seealso:: + + - ":ref:`stanislav3316-system-complexity`" + + + [Дополнение] Про профессиональные языки от Тарасенко: 💬 "Главная для нас особенность — то, что язык является универсальным средством моделирования: говорить можно о чем угодно. Из многих свойств языка, обеспечивающих ему это свойство, обратим внимание на расплывчатость смысла слов. @@ -241,10 +425,41 @@ Domain Model Definition +Классическая ошибка моделирования ограниченного контекста +--------------------------------------------------------- + +Классическая ошибка при моделировании ограниченного контекста заключается в том, что при неправильном понимании модели возникает желание "запихнуть" модель объекта моделирования в какой-то один ограниченный контекст. +Существует два самых неправильных вопроса - в какой ограниченный контекст поместить сущность и как мне получить из другого ограниченного контекста нужную сущность. + +Моделирование ограниченного контекста - это не кройка. +Плод, груз, ингредиент, блюдо - это все модели одного и того же объекта моделирования - огурца, только в разных ограниченных контекстах. +Можно рассмотреть ограниченный контекст как одну из плоскостей додека‌эдра (когда один и тот же элемент виден под разными ракурсами), а не как фрагмент пазла (когда один элемент может принадлежать только одному фрагменту полотна). + +Задача не в том, в какой ограниченный контекст "запихнуть", и не в том, как разрезать, а в том, какие именно аспекты поведения объекта моделирования релевантны в контексте решаемой проблемы. +Посетитель, пользователь, клиент, покупатель, плательщик, получатель, адресат - это все тоже модели одного и того же объекта моделирования. + +.. figure:: _media/bc_perspective.png + :alt: Different pespectives are matter + :align: center + :width: 60% + + Different pespectives are matter + + -- `Источник `__ + +Владик отлично подчеркивает это в своем примере: + + 💬 "However, it is more difficult to represent such a divergent model of the business domain in software. Source code doesn’t cope well with ambiguity. If we were to bring the sales department’s complicated model into marketing, + it would introduce complexity where it’s not needed— far more detail and behavior than marketing people need for optimizing advertising campaigns. But if we were to try to simplify the sales model according to the marketing world view, + it wouldn’t fit the sales subdomain’s needs, because it’s too simplistic for managing and optimizing the sales process. + We’d have an overengineered solution in the first case and an under-engineered one in the second." + + + Ограниченный контекст и команды разработки ------------------------------------------ -Для того чтобы реализовать модель, команда должна ее понимать, соответственно, набольшей эффективностью команда будет обладать тогда, когда граница ответственности команды совпадает с границей модели. +Для того чтобы реализовать доменную модель, команда должна ее понимать, соответственно, набольшей эффективностью команда будет обладать тогда, когда граница ответственности команды совпадает с границей модели. Это и можно назвать границей автономности рабочей команды, что позволяет команде фокусироваться на решении конкретной задачи. В ограниченном контексте команды модель обладает наибольшей внутренней связанностью (cohesion) и наименьшим сопряжением (coupling) с другими ограниченными контекстами. @@ -257,7 +472,7 @@ Domain Model Definition Если же модель поделить неправильно, допустим, разрезать полноценную модель на две разные части, то резко возрастет количество коммуникационных путей между командами (для сохранения и поддержки инвариантов модели), и этим мы ухудшаем параллелизм задач. Аналогично, если свалим в один ограниченный контекст две модели которые служат двум разным целям, то мы увеличим когнитивную нагрузку команды (путем введения информации нерелеватной в момент рассмотрения, тем самым отнимая когнитивные ресурсы у человека). -И чтобы достичь наибольшего уровня автономности команд, обеспечить их независимость друг от друга нужно правильно определить ограниченные контексты. +И чтобы достичь наибольшего уровня автономности команд, обеспечить их независимость друг от друга нужно правильно определить и снизить зависимость ограниченных контекстов. Таким образом, можно прийти к выводу, что ограниченный контекст помогает решить две проблемы: @@ -266,29 +481,14 @@ Domain Model Definition 2. Снижение коммуникативной нагрузки между командами (путем концентрации релевантных деталей) -Классическая ошибка моделирования ограниченного контекста ---------------------------------------------------------- - -Классическая ошибка при моделировании ограниченного контекста заключается в том, что при неправильном понимании модели возникает желание "запихнуть" модель объекта моделирования в какой-то один ограниченный контекст. -Существует два самых неправильных вопроса - в какой ограниченный контекст поместить сущность и как мне получить из другого ограниченного контекста нужную сущность. - -Моделирование ограниченного контекста - это не кройка. Плод, груз, ингредиент, блюдо - это все модели одного и того же объекта моделирования - огурца, только в разных ограниченных контекстах. -Можно рассмотреть ограниченный контекст как одну из плоскостей додека‌эдра (когда один и тот же элемент виден под разными ракурсами), а не как фрагмент пазла (когда один элемент может принадлежать только одному фрагменту полотна). - -Задача не в том, в какой ограниченный контекст "запихнуть", и не в том, как разрезать, а в том, какие именно аспекты поведения объекта моделирования релевантны в контексте решаемой проблемы текущего ограниченного контекста. -Посетитель, пользователь, клиент, покупатель, плательщик, получатель, адресат - это все тоже модели одного и того же объекта моделирования. - -.. figure:: _media/bc_perspective.png - :alt: Different pespectives are matter - :align: center - :width: 60% -Владик отлично выводит противоречие, как опытный диалектик: +Краткие выводы: +--------------- - 💬 "However, it is more difficult to represent such a divergent model of the business domain in software. Source code doesn’t cope well with ambiguity. If we were to bring the sales department’s complicated model into marketing, - it would introduce complexity where it’s not needed— far more detail and behavior than marketing people need for optimizing advertising campaigns. But if we were to try to simplify the sales model according to the marketing world view, - it wouldn’t fit the sales subdomain’s needs, because it’s too simplistic for managing and optimizing the sales process. - We’d have an overengineered solution in the first case and an under-engineered one in the second." +1. чтобы осознать и описать проблему, нужно сначала принять какую-то модель, систему понятий (концептуальная модель) +2. далее, мы можем приступать к поиску решения, выражаемом в виде доменой модели и способах интеграции его в новую реальность +3. ограниченный контекст модели - это области применения модели в контексте решаемой проблемы ("заказ" для бухгалтера и "заказ" для повара имеют совершенно разные контексты и соотвествтенно это разные модели для разных задач) +4. в DDD концептуальная и доменная модели, как правило, совмещены, и выражаются через единый (согласованный) язык @@ -296,7 +496,8 @@ Domain Model Definition -------------------- 1. Ivan Zakrevskii -2. Группа тг-канала объединения ИТ-архитекторов (@ru_arc) -3. DDDevotion chat (tg https://t.me/iDDDqd) -4. Группа тг-канала (@emacsway_log) о Software Design/Architecture, DDD, Microservice Architecture, Distributed Systems, SDLC, Agile, Team Topology etc. -5. рефлексия собственного опыта +2. Mikhail Andronov +3. Группа тг-канала объединения ИТ-архитекторов (@ru_arc) +4. DDDevotion chat (tg https://t.me/iDDDqd) +5. Группа тг-канала (@emacsway_log) о Software Design/Architecture, DDD, Microservice Architecture, Distributed Systems, SDLC, Agile, Team Topology etc. +6. рефлексия собственного опыта diff --git a/stanislav.bolsun/it/ddd/domain-model/system-complexity.rst b/stanislav.bolsun/it/ddd/domain-model/system-complexity.rst new file mode 100644 index 00000000..24fc73cc --- /dev/null +++ b/stanislav.bolsun/it/ddd/domain-model/system-complexity.rst @@ -0,0 +1,30 @@ +:canonical-base-url: https://dckms.github.io/system-architecture + +.. index:: Domain Model + :name: stanislav3316-system-complexity + + +============================= +Сложность как свойство систем +============================= + +.. sectionauthor:: Stanislav Bolsun + +Предельная сложность для понимания +---------------------------------- + + 💬 Одним из важнейших интеллектуальных процессов человека и проектировщика в особенности является понимание. Понимание конструкционно по своей природе. Это значит, что в процессе понимания мы соединяем различные частицы информации друг с другом при помощи особых связей, как если бы мы достраивали конструкцию. Мы соединяем те куски информации, что подходят друг к другу ближе по смыслу и углубляют понимание. Соединяем то, что вытекает одно из другого как причина и следствие. Стягивая связями подобные информационные отрывки друг с другом, мы получаем конструкцию, имеющую тот или иной смысл для нас. Смысл и является продуктом понимания. + + Так как понимание является в своей сути соединением элементов, то затруднение в понимании сложных систем связано обычно с объёмом элементов и связей, которые нужно удерживать в фокусе внимания или, говоря образно, необходимо «запихнуть в одну голову». + + 💬 "У меня когда-то был разговор с одним очень известным человеком (не буду называть фамилию), который во время аварийной ситуации вручную вывел [атомный] реактор из закритического состояния. Много времени прошло, это уже пожилой человек с орденами и медалями. Я спрашиваю: «Как?» Он ответил: «Я моделировал в голове, что происходит с реактором». Так вот, сейчас нет человека, который может смоделировать в голове, что происходит в сложной системе. Технические системы по степени своей сложности вышли за пределы интуиции инженеров-конструкторов. [П. Г. Шедровицкий, 2018]" + + -- "Пётр Щедровицкий, философ, методолог, общественный деятель" + + Вероятно для каждого отдельного человека существует некоторая предельная сложность, которую он способен воспринять или удержать в моменте, конструируя собственную овнутрённую, то есть находящуюся только в его уме, модель системы. У всех этот предел разный, но у любого проектирующего с повышением сложности системы с некоторого момента начинает не хватать когнитивных способностей справиться с ней. Обычно так и говорят: не вмещается в голову. При этом в современном мире наблюдаем отчётливый тренд на повышение сложности систем. Напрашивается вывод: инструменты управления сложностью лучше внедрять с самого начала проектирования. + + ... + + -- "Управление знаниями в продукте", https://ashapiro.ru/articles/system-episteme + +.. seealso:: Согласно закономерности `Магического числа семь плюс-минус два `__, обнаруженной американским учёным-психологом Джорджем Миллером, кратковременная человеческая память, как правило, не может запомнить и повторить более 7 ± 2 элементов. \ No newline at end of file