💬 "Impact – воздействие, которое мы собираемся сделать. Это самая сложная часть, которая мало кому дается. Я сравниваю ее с созданием гипотезы в научном методе или рождением идеи в ТРИЗ, т.е. техника понятна, но откуда берется идея, как она рождается в голове, как научить человека эти идеи создавать, решительно неясно."
-- https://habr.com/ru/articles/652577/

Это та самая причина, которая вызывает у меня неподдельный интерес к диалектической философии и теории игр. Особенно к диалектической философии. О её практичности и полезности говорит хотя бы тот факт, что она успешно существует и здравствует еще со времен Гераклита, и широко распространена на востоке (значок Инь-Янь известен, наверное, каждому). И не случайно слова "развитие", "развить" имеют значение "расплести": развить веревку, развить венок, развить косу.

Итак, чтобы развить продукт, нужно сперва развить (расплести) его противоречия. Наглядно это можно увидеть на примере того, как Владик Хононов в своей книге удивительным образом выводит противоречие, которое привело к появлению решения в виде Bounded Context.

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

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

Противоречие это заключается в том, что стремясь получить больше денег, гончар производит больше горшков. И чем больше горшков он производит, тем больше он привлекает к ним хулиганов, и тем больше величина ущерба (меньше денег). Все в точности как с проблемой о полноте и сложности модели в DDD.

И влияет это противоречие на доходность гончара.

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

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

Диалектика - это искусство, которое равно применимо и в военном деле, и в дипломатии, и в полемике, и в экономике, и в политике, и в архитектуре. Она абстрактна. Потому Морихей Уесиба и сказал, что

💬 "В Искусстве Мира нет состязаний. Истинный Воин
непобедим, поскольку он ни с кем не сражается. Когда мы говорим "нанести поражение", то имеем в виду поражение нашего собственного противоречивого ума"
-- 111 жемчужин, Морихей Уесиба

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

💬 "Всякая истина, выраженная словами, есть сила, действие которой беспредельно."
-- Л.Н.Толстой

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

Какое это все имеет отношение к архитектуре? Ключевой деятельностью в архитектуре является разрешение противоречий требований (и целей). Задача архитектора - разрешить эти противоречия до того, как они проявят себя в реализации, теряя ценность продукта в глазах пользователей. Тогда не понадобится проявление героизма для спасения продукта от самого себя. Знать, чтобы предвидеть.

Потихоньку возвращаюсь к Golang DDD Reference Application Grade. Это не только демонстрационный, но еще и вполне реальный проект, который, используя принципы теории игр, позволяет существенно повысить объективность и качество т.н. карма-движков, и повысить качество информационного пространства экспертных сообществ. А так же будет выступать альтернативой бесполезным формально-бюрократическим grade-системам ИТ-компаний на основе матриц компетентностей, которые не способствуют развитию специалистов, а, наоборот, препятствуют, оттягивая ресурсы времени на нерелевантные аспекты в ущерб релевантным. А самое главное - экспертное сообщество будет само себя квалифицировать и развивать, без всяких тестов, эталонов, экзаменаторов и пр. ограничителей развития, установивших монополию на компетентность.

С технической стороны проект принципиально не использует ORM (чтоб продемонстрировать, как можно без него обходиться); принципиально соблюдает ключевые принципы OOP, особенно инкапсуляцию, поскольку иначе технически невозможно гарантировать инварианты агрегатов; использует CQRS/EventSourcing, причем, будет реализовывать Causal Consistency посредством Causal Dependencies.

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

Если у кого-то есть желание принять участие в разработке - обращайтесь в приват ( @emacsway ). Сейчас уже вырисовываются задачи и для джунов/мидлов тоже.

#Goal #Grade

Можно ли по этой таблице, которая, к слову, единственная и состоит всего из двух колонок, сказать, что система распределения прав может объединять пользователей в группы и реализует множественное наследование прав неограниченного уровня вложенности?

# \d permission
Table "trac.permission"
Column | Type | Collation | Nullable | Default
----------+------+-----------+----------+---------
username | text | | not null |
action | text | | not null |
Indexes:
"permission_pk" PRIMARY KEY, btree (username, action)


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

💬 "Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
—Edsger W. Dijkstra, 1984 On the nature of Computing Science (EWD896)

#Management #SoftwareDesign

Если у кого-то есть желание сделать имя на действительно важной и востребованной вещи, для которой не требуется глубоких теоретических познаний (в отличии от Grade) и достаточно уровня middle по Python, то я могу подкинуть идею:

1. Портировать plugin TracHoursPlugin на Trac 1.6. Руководство по миграции:
- https://trac.edgewall.org/wiki/TracDev/PortingFromGenshiToJinja

По большей части нужно портировать только шаблоны с Genshi на Jinja2:
- https://trac.edgewall.org/wiki/TracDev/PortingFromGenshiToJinja/Example

2. Усовершенствовать этот plugin, чтобы он позволял выражать оценку в виде вероятностной распределенности в соответствии с PERT, т.е. исходя из введенных пессимистической, номинальной и оптимистической оценок вычислял вероятностную оценку и среднеквадратичное отклонение. Это несложно.

3. Доработать plugin SumFieldsPlugin, чтобы он мог складывать среднеквадратичные отклонения как корень квадратный суммы квадратов.

4. То же самое сделать с plugin ValuePropagationPlugin.

5. И то же самое - с plugin RoadmapHoursPlugin. Там уже пытались сделать костыль для обработки погрешности - нужно сделать нормально.

6. Разобраться с Gantt-плагинами, выбрать наиболее перспективный, портировать его на Trac 1.6, и научить его работать с вероятностной распределенностью.

7. Если этого показалось мало, тогда можно заглянуть сюда и сюда. На рынке мало толковых инструментов для организации грамотного планирования и процессов разработки, особенно среди Open Source. А это - хороший шанс донести свое имя грамотным управленцам вместе с инструментом, который им нужен.

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

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

В крайнем случае придётся сделать самому.

Я вижу возможным создать быстровозводимую коробочную среду управления процессами для гибридной SDLC-модели разработки с открытым исходным кодом, заточенную для небольших проектов маленьких аутсорсеров. Чтобы разворачивалось одним кликом, как когда-то Apache Bloodhound (подробнее).

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

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

Почему Trac? В силу определенной проблемости использования Jira (и её расширений) в РФ, и в результате моего исследования рынка существующих решений, я пришел к выводу, что Trac несправедливо недооценен, и архитектурно он является наиболее гибкой системой с безграничными интеграционными возможностями для автоматизации процессов и с богатым консольным интерфейсом. Остальные инструменты я со счетов тоже не сбрасываю, но, в качестве фундамента для допиливания, Trac мне видится наиболее привлекательным.

Может показаться, что Trac морально устарел перед, например, OpenProject. Но его особенность в том, что там стареть нечему. Для написания плагинов достаточно знать SQL, в то время как для написания плагинов под OpenProject нужно знать Ruby On Rails и Angular, что существенно сокращает круг контрибьюторов. Новомодный frontend на Vue под Trac тоже есть.

Но главная особенность Trac - его легче оформить в DDD-стиле с нормальными Domain Events, чем обеспечится еще более стройная расширяемость. На его базе можно создать современный и архитектурно красивый продукт. Не просто же так Vaughn Vernon выбрал именно эту предметную область для своей "Красной Книги".

Кому интересно - пишите мне в личку: @emacsway

[UPDATE]: Вводный материал по оцениванию можно посмотреть здесь.

#Management #Scheduling #Estimation #Goal

Вводный материал по оцениванию и планированию можно посмотреть здесь:
- https://news.1rj.ru/str/emacsway_log/916

Скачать литературу можно здесь:
- https://news.1rj.ru/str/emacsway_log/1078

#Scheduling #Estimation

Сделал в Trac обратное портирование поддержки Genshi шаблонов и ITemplateStreamFilter, которые широко использовались плагинами его предыдущих версий:
- https://github.com/emacsway/trac

Заманкипатчить, к сожалению, не получилось, поэтому получился форк вместо плагина. Хотя, так будет даже легче сопровождать.

Теперь для Trac 1.6 стало доступно большое количество плагинов от его версий 1.0 - 1.4 с минимальными переделками (как правило, достаточно запустить команду 2to3), что позволяет выиграть время для полноценного портирования плагинов и уже сейчас начать их использовать.

По крайней мере уже один из плагинов (для оценивания и учета времени) заработал нормально. Здесь его актуализированная версия.

Попутно поднял вопрос разработчикам ядра о том, был ли рассмотрен вариант расширения HTML посредством т.н. "циклического наследования шаблонов". Выглядит так, что этот вариант не рассматривался, но, возможно, подошел бы наилучшим образом.

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

В перспективе - создать полноценный инструмент для управления процессами гибридной SDLC-модели разработки, включая Program Backlog, Product Backlog, оценивание посредством вероятностной распределенности, управление требованиями и описание архитектуры. Все это - исключительно с открытым исходным кодом. В отдаленной перспективе - переписать все в DDD-style с нормальными Domain Events, чем обеспечится еще более стройная расширяемость.

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

#Management #Scheduling #Estimation #Goal

🔷 "Что такое сопротивление изменениям и как с ним работать?"

Автор проделал немалую работу по систематизации знаний на тему сопротивления коллектива изменениям. Этой теме посвящен весь сайт.

#Psychology #Management

🔷 "Особенности управления изменениями в России". Книга шедевральна.

#Psychology #Management

Вот так выглядело 17 лет назад то, что мы сегодня называем ADR, и в нем описывается то, что мы сегодня называем Event Sourcing:
- https://trac.edgewall.org/wiki/TracDev/Proposals/DataModel?version=1

На что можно обратить внимание? На то, что документ начинается с описания контекста. Michael Nygard предложил это делать лишь спустя 6 лет.

Там, где автор пишет "consistent change tracking and concentrate the autorship of resource modifications in one place", он фактически описывает Event Sourcing. А здесь он говорит про функциональную природу Event Sourcing: "as this can easily be reconstructed from the full history of changes".

Но самое главное - здесь хорошо видно, что архитектурное решение является балансом противоречивых требований: "balance between generality, so that the API can be the same across resources) and specificity".

Так же описаны достоинства и недостатки архитектурного решения, в соответствии с шаблоном Michael Nygard.

Авторы Trac заметно опережали свое время. Другие их "нетепличные" идеи для структуризации ADR можно посмотреть здесь.

#Documenting #EventSourcing

Представьте, что вам нужно выйти на улицу. Вы не знаете, какая там погода и температура. Как одеться?

Первый вариант - это попытаться заблаговременно предугадать погоду путем логического вывода. Например, сегодня июнь, вчера было тепло, значит, сегодня тоже должно быть тепло. И эта упрощенная модель прогноза может сработать. Это называется Prediction.

Однако, в ряде регионов России в июне выпал снег ❄

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

Второй вариант - это проверить температуру на практике - выйти на улицу. Это уже эмпирический способ обработки неопределенности, т.е. опытным путем.

Допустим, вы вышли на улицу и поняли, что футболка для снега не годится. Вы возвращаетесь и адаптируете свою экипировку под реальные условия, руководствуясь новым знанием, полученным в результате эксперимента. Это называется Adaptation.

Чтоб минимизировать стоимость адаптации, прежде, чем выйти на улицу целиком, вы открываете окно и вытягиваете на улицу руку. Вы проверили гипотезу минимизировав риски. Теперь можно выходить на улицу целиком. Это называется итерация.

Станете ли вы пытаться предугадать погоду заблаговременно, если можно легко проверить гипотезу на практике? Вероятно, что нет. Тогда у вас превалирует адаптивный способ обработки неопределенности - это итеративно-инкрементальная SDLC-модель разработки, или её разновидность - Agile.

Ок, но вы живете на 150-м этаже, окна не открываются - климат-контроль. Прежде чем выйти на улицу и проверить гипотезу на практике, вы уже взвешиваете риски, чтобы минимизировать вероятность адаптации. Т.е. пытаетесь сперва разрешить неопределенность заблаговременно, путем логического вывода, и лишь затем - закрепить результат путем практического эксперимента. Это уже гибридная или спиральная SDLC-модель.

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

У вас есть свое мнение о погоде, но вы спрашиваете мнение соседа - как он думает, какая погода на улице? Вы формируете коллективное мнение. Сосед говорит - холодно. Вы говорите - тепло. Это называется противоречие. Противоречие и отсутствие возможности проверить мнение на практике (эмпирическая проверяемость) говорит о том, что вы не знаете, какая на самом деле погода. Тут вдруг поднимается по лестнице еще один сосед с улицы. Вы спрашиваете у него о погоде - он отвечает. Противоречие устраняется, и одно из мнений проходит эмпирическую проверяемость - это называется знание.

Неверно выбранная Agile модель разработки - это все равно, что спускаться 150 этажей пешком для того, чтобы узнать как одеться перед выходом на улицу. Чтобы этого не допустить, литература по архитектуре приводит критерии выбора SDLC-модели разработки. В простейшем случае - это Cynefin framework. В более сложном случае - статьи и книги Barry Boehm.

См. также краткий справочник по SDLC.

#Agile #DDD

@gradea справедливо напомнил, что Adaptation можно сравнить с метафорой Gregor Hohpe о продаже опционов на фондовом рынке.

Пролистал книгу "Domain-Driven Design with Golang" by Matthew Boyle

Образцы кода к книге:
- https://github.com/PacktPublishing/Domain-Driven-Design-with-GoLang

Исчерпывающего руководства не получилось. Есть косяки. Острейшие проблемы обошли стороной.

Но для расширения кругозора полистать можно.

Кстати, я смотрю, в справочнике ссылок по DDD+Golang появилось много нового.

#DDD #Golang

А вот этот Golang DDD ES/CQRS Reference Application от контрибьюторов EventStore посмотреть было уже интересно. Многие вещи реализованы довольно грамотно. Есть на что посмотреть.
- https://github.com/EventStore/training-advanced-go

#Golang #DDD #EventSourcing #CQRS

Один из острейших вопросов при разработке frontend с применением CQRS-like State Manager (Redux, Vuex, Pinia, NgRx etc.) - это где размещать бизнес-логику, в actions или в reducers. Однозначного ответа не дает никто, и это делает вопрос интересным.

Авторы Redux затрагивают этот вопрос здесь: "Where should my “business logic” go?"

Итак, по порядку.

1. На фронте нет "бизнес-логики", если это только не offline-first и не peer-to-peer приложение. Задача UI - предоставить пользователю Read Model, чтобы он смог сформировать валидную Команду (CQRS-Command). А эта задача в корне отличается от проверки инвариантов Агрегата.

2. Ребята от IBM приходят на помощь и устраняют эту путаницу в размещении логики:

💬 "There is no concept of reducers, meaning that there is no confusion about where logic needs to reside between reducers and actions. Commands are the only place that state logic resides and return operations that dictate what state changes are required and processed internally by the store."
-- Dojo Stores

Они разработали архитектурно более правильную версию Redux, которая более понятна разработчикам с опытом в CQRS.

Вот только они не уточнили, о какой именно логике идет речь - Application или Domain, если это все-таки offline-first приложение.

Под термином Operation здесь понимается Domain Event, лишенный своей семантики. И эта подписка, по сути, тождественна подписке на Domain Event.

А здесь, по сути, осуществляется накопление Reversing Domain Events в виде компенсационных Operations.

Это лучший CQRS-like State Manager, который я видел. Но тем не менее, меня не привлекает идея превращать осмысленные Domain Event в семантически бессмысленные Operations по образу WAL. По этой причине я бы предпочел не использовать вообще никакого Vendor Lock, тем более, что ряд из них уже не раз потрясал своих пользователей обратно-несовместимыми релизами, а то и вовсе прекращением развития в пользу другого решения (например, Vuex -> Pinia, или Redux -> Hooks).

Классический Mediator по образу MediatR пишется всего за несколько минут, гарантируя независимость от потрясений любого вендора.

Резонно возникает вопрос, а где в таком случае должен быть Агрегат, ну, если он должен быть?

Агрегат должен быть при выполнении двух условий:
2.1. Domain Logic реально присутствует на стороне Frontend, см. п.1.
2.2. Frontend выполнен не в функциональной парадигме, см. подробнее здесь. Дело в том, что функция агрегата - обеспечить контроль над изменяемостью его состояния. В FP нет изменяемости, соответственно, отпадает надобность в её контроле.

Однако, мы помним, как B.Mayer сказал:

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

Почему он так сказал? На этот вопрос отвечает Eric Evans:

💬 "If the framework's partitioning conventions pull apart the elements implementing the conceptual objects, the code no longer reveals the model.

There is only so much partitioning a mind can stitch back together, and if the framework uses it all up, the domain developers lose their ability to chunk the model into meaningful pieces."
-- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans

Это и есть основная проблема при использовании Redux в больших приложениях - фрагментация логики превышает возможности краткосрочной памяти человека.

Кроме того, сама суть CQS заключается в том, чтобы позволить использовать преимущества как функциональной парадигмы (Query), так и императивной (Command), т.е. комбинировать их в одной программе.

Место Агрегата в таком случае хорошо указал Udi Dahan в статье "Clarified CQRS", см. первую картинку.

В таком случае, Reducer/CommandHandler содержит логику уровня Application Layer и осуществляет действие над Агрегатом.

И здесь на первое место выходит вопрос о том, каким образом будет биндиться агрегат на его HTML-отображение. Например, можно применить самодельный View Model (см. главу "Duplicate Observed Data" книги "Refactoring: Improving the Design of Existing Code" 1st edition").

Продолжение.

Часть 2.

В рассмотренном выше варианте сам Store может хранить Доменную модель. Выглядеть это будет примерно так.

3. Есть и иной вариант, когда Command никаким образом не связана со Store и является отдельной надстройкой, а Store превращается, по сути, в обработчик Domain Events, обеспечивая биндинг Агрегата на его HTML-представление. Почти такой же вариант описывает @oleglustenkome в чате канала. И здесь.

Спасибо участникам дискуссии за замечание - я должен внести правку в предыдущее сообщение.

> На фронте нет "бизнес-логики", если это только не offline-first и не pear-to-pear приложение. Задача UI - предоставить пользователю Read Model, чтобы он смог сформировать валидную Команду (CQRS-Command). А эта задача в корне отличается от проверки инвариантов Агрегата.

Здесь имелась ввиду полноценная доменная модель вместе с инвариантами агрегатов. Потому что, если прочитать буквально, то обнаруживается противоречие, поскольку Команды тоже относятся к бизнес-логике, хотя их обработчики часто реализуются на уровне Application в силу DDD-трилеммы.

О роли однонаправленного потока изменений см. здесь (копия).

Awesome списки для выбора библиотеки управления состоянием на стороне клиента:
https://github.com/tnfe/awesome-state

Прочитал статью "Angular Service Layers: Redux, RxJs and Ngrx Store - When to Use a Store And Why?"

В целом, статья неплохая. Кое-что я почерпнул. Правда, материал не настолько исчерпывающий по этой теме, как "Object-Oriented Software Construction" 2nd edition by Bertrand Meyer.

Причиной внедрения Flux в практику Facebook стала потребность в реал-тайм синхронизации состояний клиентов, и решение было найдено в виде однонаправленного потока изменений:

💬 "editing the same data by multiple concurrent actors"

Причина, по которой Redux синхронный, заключается в сложности организации Causal Consistency, когда события могут выстраиваться в случайный порядок.

Так же, как и авторы Dojo Store, автор статьи утверждает, что Action - это Команда, а не событие:

💬 "Redux looks like an event bus, but it's not. Actually, a Redux store is a combination of the Command and the Observable patterns. What we do with the store is, we send it a command object known as an action:"

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

Кстати, путаницу между командами и событиями попытались прояснить еще и авторы NgXs.

Еще одним явным отличительным признаком Команды является единственность её получателя/исполнителя.

Важный момент - данные в Store названы "моделью" (это уже второй признак в пользу "первого варианта", т.е. п.2, озвученного здесь):

💬 "the user triggers an action, its gets dispatched to the stores which generate a new model and send it to the view."

Чего не хватило в статье, так это фундаментальности. Трудно объяснить достоинства Redux, обойдя стороной достоинства CQRS.

#CQRS #Frontend

Наконец-то перенес в публичную часть блокнота заметку про отличие между Repository и Adapter (Ports & Adapters).

#DDD #Repository #HexagonalArchitectire

🔷 "Эффективные надежные микросервисы" блог компании Одноклассники

Интересный опыт.

#Microservices

🔷 "Architecture vs. Design" by George Fairbanks. Интересные размышления.

#SoftwareArchitecture #SoftwareDesign