Пятничное чтиво

Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.

—————————————

Aligning organization and architecture with strategic DDD

Когда говорят о DDD сразу представляют энтити объекты, агрегаты и value objects, т.е. Domain Model паттерн, который моделирует предметную область, состоящей из кучи стейт транзишенов, бизнесовых валидаций и прочего. При этом, анализ того, что надо смоделировать и почему именно эту модель - опускается как в книгах, так и в статьях, хотя вопрос без анализа реализация теряет смысл от domain model паттерна. Если начать разбираться, то можно выйти на два уровня DDD - стратегический и тактический, где тактический как раз реализация модели, а стратегический - понимание домена.

Это первый раз, когда в ссылках слайды. Но при этом, данные слайды - ускоренный способ понять что такое и какие проблемы решает стратегический DDD. Найдете объяснение problem и solution space, что такое домен, поддомен, какие виды поддоменов есть и в чем отличие, при чем тут Ubiquitous Language и почему bounded context - часть solution space. А также разбор context mapping и краткий пересказ team topology. Сами слайды не ответят на вопросы, но позволят собрать картину в голове.

#ddd #strategic_ddd

—————————————

The Modern Observability Problem

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

Для начала приводится определение телеметрии - понимания внутренней работы системы. Иногда телеметрию называют сигналами. При этом логирование, метрики и трейсинг - варианты телеметрии, которые используются в software системах. После чего автор пытается ответить на вопрос, что же такое “правильная” телеметрия. И в качестве ответа, предлагается задавать вопросы, например: “что мешает акторам выполнять работу?”. Т.е. собирать метрики, которые позволят ответить на значимые для бизнеса вопросы по работе системы. После чего идет рассуждение о технологиях и форматах телеметрии.

#observability

—————————————

Stop writing bad documentation… Write RFCs instead

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

Описанная выше проблема решается документацией. Например, это может быть ADR, но это не единственный способ. Можно воспользоваться RFC (Request For Comments) - документ, описывающий решаемую проблему, рассмотренные опции и итоговую реализацию. В отличии от ADR, где описывается решение, RFC крутиться вокруг получения обратной связи вокруг планов и принятия решений. В тексте выше рассказывается, как использование RFC помогает в обучении, коммуникации. А также, как писать документы и из чего они состоят.

#rfc #decision_making