Пишу своими руками сейчас два проекта. Один - по всем канонам DDD на малознакомом мне стэке. Другой - по документации Django Framework. Я уже говорил об этом.

По прошествии двух месяцев могу поделиться впечатлениями.

1. Скорость разработки на Django, все-таки быстрее, но не слишком существенно.

Это потому, что Django во всю использует рефлексию для минимизации количества кода.

Известно два способа решения этой проблемы - "reflective program" и "code generation", подробнее см. в главе "Metadata Mapping" книги "Patterns of Enterprise Application Architecture" by M.Fowler.

Таким образом, чтоб парировать превосходство Django Framework, нужно делать генератор кода для DDD-проектов. Тогда скорость разработки даже существенно превзойдет скорость на Django.

Основные потери времени на Django составляет борьба с Framework в каждом нетипичном кейсе. Это от 30% до 50% времени разработки.

В свою очередь, проект по DDD требует время на исследовательскую работу по способу структурирования кода.

2. Django накладывает более строгие требования к способности выдерживать когнитивные нагрузки. Нередко приходится погружаться в потроха Фреймворка, понимать его реализацию (а Django сегодня не такая уж и простая, как была 10 лет тому назад). Обзор и инспекция её плагинов так же требует погружения в детали их реализации. Встречались случаи, например, грубого нарушения потокобезопасности. Так что Django накладывает более строгие требования к квалификации исполнителя, кто бы не убеждал в обратном.

Однако, проект с чистого листа по DDD требует невероятно глубоких познаний и обширную работу с литературой. Хорошо то, что эти затраты однократны. Если под рукой уже есть сформированный качественный образец (а лучше - генератор кода), то справится любой мидл.

3. Моральное удовлетворение больше приносит разработка по DDD. Это чувство можно сравнить с выплаченным кредитом - теперь ты не заложник обстоятельств. Чувство свободы и независимости.

Если вы смотрели сериал "Is TDD Dead?", то заметили, что претензии David Heinemeier Hansson касались не столько TDD, сколько принципов Clean Architecture.

В принципе, для заказной разработки вполне пригодна разработка по Framework без всяких там DDD или Clean Architecture, и зачастую она способна дать существенный прирост темпов разработки.

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

Как организовать БД для запуска интеграционных тестов на Golang? Да еще и чтобы можно было запускать тестовые кейсы параллельно, обеспечивая при этом изоляцию данных?

Ребята подготовили два решения, которые создают отдельную копию БД для каждого параллельного потока:

- https://github.com/pantafive/demo-repository-test by @pantafive

- https://github.com/xorcare/testing-go-code-with-postgres by @xorcare

Там же продемонстрировано как это сделать на GitHub workflow.

Все элегантно и просто. Мне это оказало неоценимую помощь при освоении малознакомого мне стэка.

#Golang #Testing

В продолжение предыдущего сообщения - еще Kent Beck писал о проблеме "Borrowing Trouble", которую я называю "проблемой умных людей". Практика показывает, что эта проблема широко распространена. Наиболее умные разработчики зачастую работают гораздо медленнее посредственных. Но ситуация кардинально меняется, если им объяснить причины этого.

И еще пара ссылок в тему:

- https://habr.com/ru/company/web_payment_ru/blog/246081/

- https://www.hindawi.com/journals/np/2009/482696/

О проекте "Архитектурные этюды".

Список топиков: https://news.1rj.ru/str/archicases

Главный топик (для вступления): https://news.1rj.ru/str/archicases/1

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

В отличии от других сообществ, которые создают топики обсуждения по конкретным областям знаний, @sergey486 решил создавать топики по конкретным кейсам. Тем самым он еще больше облегчил поиск решения на основе схожести проблемы. Именно возможность навигации на основе схожести проблемы является причиной роста популярности эталонно-демонстрационных приложений. Как говорится, лучше один раз увидеть. Именно по этой причине Example Mapping стал таким популярным.

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

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

Какие вопросы еще остаются нерешенными?

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

Остается открытым вопрос организации защиты информационного пространства от захламления откровенно недостоверными вбросами, а также от проявлений эффекта Даннинга-Крюгера, субъективизма и вкусовщины. Модерация пока остаётся единственным и не самым действенным механизмом. Новичкам не всегда понятно кого слушать, а грамотные специалисты не всегда спешат ввязываться во флейм. Но, должен заметить, что уровень конструктивности и морально-психологического климата ему удалось значительно повысить по сравнению с аналогичными экспертными тг-сообществами.

Это сложные проблемы, и прецедентов их успешного решения в отрасли крайне мало. Решением этих проблем занимается Теория Игр.

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

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

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

[UPDATE]: после регистрации требуется пройти спам-тест в главном топике https://news.1rj.ru/str/archicases/1 за 60 сек.

Хорошие курсы по оптимизации PostgreSQL:
- https://postgrespro.ru/education/courses/QPT

Коллеги, есть ли кто из юристов с опытом в налогообложении? Есть вопросик. Напишите в личку, пожалуйста: @emacsway

Актуальное видео в нашей профессиональной среде:
https://youtu.be/hm-vYGXx3Aw

Классическая ошибка при моделировании 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://news.1rj.ru/str/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

Вместо упрощения подходов к описанию архитектур они усложняются

Новые сущности, появившиеся в прошлогодней версии стандарта ISO 42010, на рисунке, опубликованном на сайте рабочей группы

[1] Источник картинки
[2] Чуть подробней об изменениях в стандартах 420x0 в моем блоге

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

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

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

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:
- "Обдумывая стори поинты"

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

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