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

В крупных приложениях этого, к сожалению, недостаточно, т.к. сам доменный слой тоже может расслаиваться, см. главу 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/

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

Список топиков: https://www.tgoop.com/archicases

Главный топик (для вступления): https://www.tgoop.com/archicases/1

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

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

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

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

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

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

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

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

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

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

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

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

Update, еще одна книжка от автора топологии команд:

Remote Team Interactions Workbook: Using Team Topologies Patterns for Remote Working https://a.co/d/6VCTWNc

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

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

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