По результатам опроса большинство предпочитает инкрементировать версию Агрегата единожды на транзакцию, а не на Доменное Событие (на факт изменения состояния).

Хочу поделиться результатом своих двухдневных размышлений по этому поводу, которые вынудили меня изменить эту точку зрения:
- https://dckms.github.io/system-architecture/emacsway/it/ddd/tactical-design/repository/causal-consistency.html

А какие у вас соображения по этому поводу?

#DDD #DistributedSystems #Microservices #CausalConsistency

В следующем сообщении говорится о том, почему я для EventStorming использую Archi - чтобы с математической точностью вычислять наилучшую конфигурацию контуров микросервисов на основании принципа Low Coupling & High Cohesion:

Cranking out lines of code isn’t the most value-add activity for architects. But understanding system structures and hidden dependencies is, and debugging is all about that

Gregor Hohpe начинает 2023 год с разговора на нашу любимую тему: "Должен ли архитектор писать код" и приходит к неожиданному выводу о большей пользе для архитектора от участия в отладке: https://architectelevator.com/transformation/debugging-architect/

Обещал найти ссылку о применимости шаблона описания архитектурных решений ADR для более широкого класса решений.
Делюсь: ADR = Any Decision Record? Architecture, Design and Beyond

Краткое графическое введение в c4model от IcePanel

https://blog.icepanel.io/2022/10/03/c4-model-for-system-architecture-design/

Долгое время единственным ISO-шным стандартом по архитектуре оставался ISO/IEC/IEEE 42010:2011 Systems and software engineering — Architecture denoscription. В 2019 году появились сразу два новых архитектурных стандарта 42020 и 42030. А в ноябре прошлого, 2022 года обновился и основной стандарт описания архитектуры.

Как именно, читайте здесь: https://mxsmirnov.com/changes-420x0/

В крупных приложениях этого, к сожалению, недостаточно, т.к. сам доменный слой тоже может расслаиваться, см. главу 16-17 книги Eric Evans.

Пишу своими руками сейчас два проекта. Один - по всем канонам 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/