Классическая ошибка при моделировании Bounded Context (BC), Microservice, Aggregate заключается в том, что при неправильном понимании модели возникает желание запихнуть модель объекта моделирования в какой-то один BC.

Два самых неправильных вопроса - в какой BC поместить сущность и как мне получить из другого BC нужную сущность.

Моделирование BC - это не кройка. Плод, груз, ингредиент, блюдо - это все модели одного и того же объекта моделирования - огурца, только в разных BC. Думайте о BC как о плоскости додека‌эдра (когда один и тот же элемент виден под разными углами с разных плоскостей додека‌эдра), а не как о фрагменте пазла (когда один элемент может принадлежать только одному фрагменту полотна). Задача не в том, в какой BC запихнуть, и не в том, как разрезать, а в том, какие именно аспекты поведения объекта моделирования релевантны в контексте решаемой проблемы текущего BC. Посетитель, пользователь, клиент, покупатель, плательщик, получатель, адресат - это все тоже модели одного и того же объекта моделирования.

Как сказал Alberto Brandolini:
💬 Different wording may refer to different perspectives on the same event, hinting that this might be relevant in more than one Bounded Context, or that the two or more events aren’t the same thing.
-- Introducing EventStorming

То же касается и агрегатов. Самый неправильный вопрос - "у меня один агрегат зависит от другого, можно ли их объединить в один агрегат..."

Вот агрегат ProductBacklogItem:
https://github.com/VaughnVernon/IDDD_Samples/blob/master/iddd_agilepm/src/main/java/com/saasovation/agilepm/domain/model/product/ProductBacklogItem.java

А вот сущность CommittedBacklogItem агрегата Sprint:
https://github.com/VaughnVernon/IDDD_Samples/blob/master/iddd_agilepm/src/main/java/com/saasovation/agilepm/domain/model/product/sprint/CommittedBacklogItem.java

И первый, и второй моделируют один и тот же объект. Только в первом случае - агрегат, во втором - сущность иного агрегата.

#DDD

Alberto Brandolini в своей книге пишет, что ему было сложно уловить смысл BC. Это было самое сложное для него.

💬 "Among the many ideas coming with Domain-Driven Design, Bounded Contexts have been initially hard to grasp, at least for me. It took me a while to realize how powerful and fundamental this concept is."

- "Leanpub: Introducing EventStorming" by Alberto Brandolini

От себя добавлю, что начал понимать Bounded Context лишь спустя несколько лет после прочтения Эванса. И окончательно понял лишь после прочтения книги "Прикладной системный анализ" / Ф.П. Тарасенко.

@xorcare написал статью по теме параллельного тестирования интеграционных тестов с БД:
"Как протестировать код на Go с базой данных?"

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

Исходный код к статье публиковался ранее.

#Golang #Testing

Поиск решения на основе схожести проблемы обретает популярность не только в архитектуре (https://www.tgoop.com/archicases , https://bytebytego.com/ ), но и в OSINT:
- https://osint-mindset.gitbook.io/cases/dom-kotoryi

На конкретных примерах приводятся решения по обнаружению геолокации фотографии и др.

🔷 "Counter-OSINT: руководство по приватности и защите своих данных в Сети"

Я и не знал, что так можно:
https://github.com/archimatetool/archi/issues/265#issuecomment-447963893

Всегда делал заменой в текстовых файлах:
https://github.com/archi-contribs/archi-grafico-plugin/wiki/GRAFICO-explained

[UPDATE]: Итоговый результат здесь:
https://github.com/archimatetool/archi/issues/663#issuecomment-674039925

Часто говорят, что вот как формировать Bounded Context - еще более-менее понятно, а вот как выявлять Subdomain?

💬 Domains are synonymous with business capabilities from the business architecture world.
-- "Architecture Ownership Patterns For Team Topologies. Part 1: A Business Architecture Model" by Nick Tune

💬 The Enterprise Architecture world uses the concept of Business Capabilities at different levels. Business Capabilities can be viewed as domains and subdomains.
-- "Domain, Subdomain, Bounded Context, Problem/Solution Space in DDD: Clearly Defined" by Nick Tune

💬 A subdomain is a subpart of a domain, and specifically applicable within Scope 3. It’s often the case that a subdomain is the same as a business capability.
-- "Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture" by Vaughn Vernon

Дальше все по TOGAF с помощью Archimate.

[UPDATE]: See also "Product & Domain-Oriented Business Architecture Building Blocks"

#DDD

💬 How to Identify Sub-Domains

Domain knowledge is key to decomposing a domain into sub-domains that have a high level of internal cohesion and minimum dependencies with other sub-domains. Conducting an event storming workshop is a great way to accelerate the acquisition of domain knowledge and explore domain decomposition scenarios.

-- OA-Standard, chapter "20.1.1. Domains and Sub-Domains"
https://pubs.opengroup.org/architecture/o-aa-standard/DDD-strategic-patterns.html#KLP-DDD-sub-domains

Говорят, что молодые специалисты сейчас мало читают, но много смотрят видео.

Скажу честно, я видео не смотрю почти никогда, за редким исключением.

Причин несколько.

1. Низкая скорость усвоения информации. Чтение банально быстрее примерно на порядок.

2. Низкое качество информации. Степень продуманности, дистилляции и структуризации письменной информации все-таки выше. Меньше воды. Именно по этой причине мало кто любит "голосовухи в телеге".

3. Мне не нужно слушать все подряд. Мне нужно выделить только релевантную информацию и проскочить нерелевантную. Чтение облегчает это.

4. Хронологическая информация мало полезна. Существует даже т.н. "синдром коллекционера", когда информация накапливается, а навигация в этом бесструктурном массиве информации утрачивается. Письменная информация, в отличии от видео, структурирована. По тексту отлично работает полнотекстовый поиск. Я легко могу находить даже то, что никогда не читал.

5. Письменную информацию легче конспектировать в электронном блокноте или делать пометки в читалке.

6. https://dckms.github.io/system-architecture/emacsway/soft-skills/learning.html

7. https://dckms.github.io/system-architecture/README.html#id11

Кто-то красиво сказал, что люди делятся на две категории: на тех, кто читает, и на тех, кто слушает тех, кто читает.

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

Перевод оригинальной статьи Ron Jeffries о Story Point:
- "Обдумывая стори поинты"

Ценнейшая информация. Напомню, что он считается их изобретателем.

О приоритезации грамотным языком. Картинка в статье бесценна.
- "Определите свои классы обслуживания с помощью Триаж Таблиц"

Пообщался со @schetinnikov . Выяснилось, что он имеет преподавательский опыт и неплохие спикерские навыки. Глубоко знает проблематику DDD и умеет интересно вести дискуссию. Дискуссия настолько получилась увлекательной, что я предложил проводить подобные дискуссии на регулярной основе более широким кругом.

Кто за - пишите в комментариях (ибо лайки анонимны) 🙂

Так вот откуда эта повальная тяга к говнокоду, когда каждый спринт производится по системному инкременту экскременту. Спасибо друзьям, разъяснили:
https://dzen.ru/a/X4QlsEKmlnP3zjoN

Даже самые выдающиеся авторы обсуждают эту тему на конференциях мирового масштаба:
https://www.tgoop.com/ru_arc_chat/14208

[UPDATE]: Рекорд цены за 30 грамм отходов жизнедеятельности Пьеро Мандзони был поставлен в мае 2008 года на аукциона Sotheby's – банка №83 была продана с молотка за 97250 фунтов стерлингов. Получается, что сегодня дерьмо художника почти в 100 раз дороже золота.

Часто спрашивают, как сделать так, чтоб изменение вступило в силу в нужный момент времени. По разным причинам. Например, нужно обработать много данных, но чтоб результат стал видим единовременно.

Новая статья Kent Beck как раз об этом:
🔷 "Eventual Business Consistency"

См. также:

🔷 https://martinfowler.com/eaaDev/timeNarrative.html
🔷 https://martinfowler.com/eaaDev/TemporalObject.html
🔷 https://martinfowler.com/eaaDev/TemporalProperty.html
🔷 https://martinfowler.com/eaaDev/Effectivity.html
🔷 https://martinfowler.com/eaaDev/Snapshot.html

Есть идея. Допустим, вы являетесь успешным специалистом, и хотите освоить новый аспект знаний, например, EventStorming.

Как говорится, лучший способ что-то понять - это попытаться объяснить это другому человеку.

Лучший способ кристаллизировать знания - это работать с информацией письменно, чтоб она была отчуждаема.

Допустим, на этом еще и зарабатывать - оформить свои заметки в виде учебного курса и получать регулярный роялти. При этом заручиться менторством и рецензированием от меня или других известных ребят.

И этот курс будет создавать вам имя и укреплять карьерные перспективы.

Кому было бы интересно, поставьте 👍, пожалуйста. Интересно оценить осуществимость идеи.

Еще одна идея. Вернее, две, но обо всем по порядку.

Я в последний месяц смог позволить себе появиться в тг-групах. Вопросы задают все те же, и ответы на них те же. Я дал несколько ответов, которые мне самому показались интересными. Из-за дефицита времени иногда приходилось отвечать устно, например, https://www.tgoop.com/iDDDqd/21557 .

К сожалению, личные обстоятельства не позволяют мне оформить мою же информацию и опубликовать в электронном блокноте.

Вы знаете, что у меня есть блокнот, состоящий из приватной, корпоративной и публичной частей. Публичная часть доступна здесь:
https://dckms.github.io/system-architecture/

Алфавитный указатель:
https://dckms.github.io/system-architecture/genindex.html

Этот блокнот имеет несколько особенностей:

1. Как вы знаете, в Zettelkasten используется тегирование вместо рубрикации потому, что узел древовидного дерева рубрикатора не может принадлежать нескольким родителям. В моем блокноте на sphinx-doc это возможно, что позволяет организовать многопользовательскую среду, в которой у каждого из авторов есть свое собственное дерево навигации, в которое он может вставлять статьи и поддеревья из деревьев навигации других авторов. Также можно создавать общее, главное дерево навигации. В общем, перекрестные деревья - невероятно мощный механизм, который незаслуженно недооценнен.

Иными словами, этот инструмент позволяет гибко переплетать собственный блокнот с чужими блокнотами. А поскольку весь персональный контент одного пользователя лежит в его отдельной директории, то становится возможным персонализировать лицензионную политику.

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

Подробнее о других возможностях см. здесь:
https://dckms.github.io/system-architecture/README.html#id13

Полное описание:
https://dckms.github.io/system-architecture/README.html

Возникший дефицит времени вынуждает меня искать новые формы решений. Возникает идея.

Любой может задать мне вопрос в канале этого чата:
https://www.tgoop.com/emacsway_chat

Мой ответ может быть полным или неполным, например, "посмотрите в книге такой-то по словам таким-то". Может быть устным, а может быть письменным.

Автор вопроса прорабатывает ответ и оформляет полученный инкремент знаний в отчуждаемом виде в коллективно-распределенном электронном блокноте
https://github.com/dckms/system-architecture/
под моим наставничеством и рецензированием.

Попытка объяснить полученное знание другому человеку в отчуждаемом виде является невероятно мощным инструментом кристаллизации собственных знаний. Лучший способ что-то понять - это попытаться объяснить это другому человеку.

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

Таким образом, польза будет обоюдная. И это позволит консолидировать усилия сообщества на формирование справочного руководства, позволяя каждому сохранить свое авторство и лицензионную политику.

Наиболее хороший материал будет включаться в главное навигационное дерево блокнота.

Что думаете по этому поводу? Кто готов принять участие, поставьте, пожалуйста, 👍, чтоб я смог оценить жизнеспособность идеи.

В идеале хотелось бы сформировать стабильный коллектив.

Также нужны помощники по переносу материалов этого канала в блокнот, например,
- https://www.tgoop.com/emacsway_log/1113
- https://www.tgoop.com/emacsway_log/1074
и др. Если кто-то готов подключиться к процессу, пишите мне в приват @emacsway или в чат канала @emacsway_chat .

Вторую идею напишу позже.

Да, кстати, эта идея ни в коем случае не заменяет предыдущую.

🔷 "Как выбрать коммерческие курсы, обучающие ИТ-профессии" / Денис Бесков

«Архитектура – это равновесие,
мастер – это тот, кто умеет привести силы природы в равновесие,
мастерство – это умение привести силы природы в равновесие,
творчество – это желание привести силы природы в равновесие»

https://cyberleninka.ru/article/n/kontsept-masterstva-i-mastera-v-arhitekture