Архитектура - это как игра в шахматы. Из огромного количества вариантов ходов мы оставляем лишь те, которые приводят нас к цели. Т.е. архитектура, как и шахматы, - это о том, как не надо делать. На эту тему уже были посты:

- https://www.tgoop.com/emacsway_log/1022
- https://www.tgoop.com/emacsway_log/1181
- https://www.tgoop.com/emacsway_log/1285

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

Шахматы - удивительная наука, которая стоит на стыке политики, воинского искусства (все-таки, это модель двух средневековых армий), моделирования, математики, теории игр (стратегические игры), алгоритмов, искусственного интеллекта, планирования, психологии и, кажется, список можно продолжать.

Они развивают стратегическое мышление, тактику, выдержку. Те качества, которые критически необходимы архитектору или управленцу.

А самое главное, они прививают любовь к постоянной борьбе. Делают борьбу постоянным состоянием. А ведь "software design is a constant battle with complexity" -- Eric Evans.

Практически все выдающиеся исторические деятели увлекались шахматами, от Ивана Грозного до современников.

Для меня наличие шахмат среди хобби соискателя - это огромный "зеленый флаг".

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

Коротко о том, чем отличается Event Sourcing от Mutable State Storage. Ну и заодно о том, чем отличается Функциональная Парадигма от Императивной.

В первом варианте ничего не изменяется - есть только append-only event log.

Во втором варианте каждое шахматное поле представлено изменяемой переменной с текущим значением поля.

Второй вариант является математической свёрткой событий первого варианта. Соответственно, первый вариант позволяет восстановить состояние на любой момент времени.

Первый вариант (Event Sourcing) часто используется совместно со вторым (CQRS Read Model).

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

Иными словами, архитектура - это постоянная борьба, и шахматы в этом вопросе оказываются очень символичными, хорошо развивая необходимые качества архитектора. Представьте, что за белых играет архитектор, а за черных - Product Owner, который постоянно наровит изменить требования и поставить систему под удар новых требований.

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

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

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

С Product Owner, играющим в шахматы, намного легче развивать систему. Фактически он уже владеет основами системного мышления.

В статьях
https://habr.com/ru/company/cian/blog/569940/
и
https://less.works/ru/less/principles/systems-thinking
приводятся примеры радикальных последствий в тех случаях, когда лицо принимающее решение (ЛПР) плохо понимает основы системного мышления и попадает в ловушку ложной коммутативности.

Образно говоря, существуют ЛПР, которые думают, что при ремонте квартиры сперва можно сделать стены а потом выравнивать пол. Это равносильно тому, чтоб утверждать, будто не имеет значения какими фигурами и в какой последовательности ходить в шахматах. Шахматы хорошо приобщают к системному мышлению. А значит, приобщая ЛПР к шахматам, вы приобщаете его к системному мышлению и способствуете взаимному пониманию двух противоборствующих сторон разработки.

[UPDATE]: отдельного внимания заслуживает понятие "развитости фигур". Т.е. при взятии/жертвовании фигуры имеет значение не только вес фигуры, но и то, сколько ходов в эту фигуру уже вложено. Т.е. оценка превосходства по времени и трудоёмкости.

Если кто еще не подписан на канал Андрея Кузнецова - настоятельно рекомендую. Грамотный спец. Не раз обсуждал с ним сложнейшие вопросы по безопасности.

FINDING SOFTWARE BOUNDARIES
FOR FAST FLOW
Team Topologies and Domain-Driven Design

О дихотомии функции и конструкции на примере шахмат.

В шахматах существует такой тактический прием, как связывание:
https://chessrussian.ru/materialy/beginners/svyazka-primenenie-svyazki/

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

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

Связанную фигуру можно так же рассматривать в качестве слоя трансляции - чтобы защитить свою доменную модель (самую дорогую часть ПО), мы создаем слой трансляции под названием Open Host Service:
this approach of inserting a translation layer for each external system avoids corruption of the models with a minimum of cost
http://ddd.fed.wiki.org/view/open-host-service

Т.е. чтобы предотвратить разрушение модели/конструкции. Все как и в шахматном связывании.

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

См. также.

Может кому-нибудь пригодится для реализации критериев выборки (фильтрации) Public-API по Style Guide AIP-160 by Google:
- https://github.com/einride/aip-go
- https://github.com/aip-dev/google.aip.dev/issues/684
- https://github.com/aip-dev/google.aip.dev/issues/738
- https://google.aip.dev/160
- https://github.com/google/cel-spec
Другие варианты смотрите здесь:
- https://dckms.github.io/system-architecture/emacsway/it/self-education/self-education-for-software-engineer.html#api-design

Только что обнаружил, что Greg Young тоже опубликовал 16 ноября пост на шахматную тематику.

[UPDATE]: И, кажется, он это делает систематически. Видимо, не я один заинтересовался шахматами на почве ИТ-архитектуры.

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

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

Основное принцип - доска всегда должна быть перед глазами, на самом видном месте. Её функции больше психологические - она создает контекст погружения в обстановку. И помогает в борьбе с Первым Законом Паркинсона, но это уже отдельная тема для обсуждения, - для эффективного её решения нужны две доски на два спринта.

Так вот, к чему это я. Некоторые мои в т.ч. широко известные коллеги используют бумажный ежедневник, чем неоднократно вводили меня в замешательство. Я считал это рудиментарными привычками. Но недавно у меня появилась хорошая перьевая ручка и мне захотелось купить себе бумажный ежедневник. После непродолжительных поисков мой выбор пал на блокнот fineplan формата A6 на кольцах из натуральной кожи коньячного цвета с тиснением под крокодила. Он у меня всегда раскрыт возле монитора и выполняет те же функции, что и физическая Agile-доска, - постоянно визуализирует образное представление моего личного распорядка перед глазами. Эстетичность блокнота и ручки вызывает желание ими пользоваться. За несколько дней заметил существенное улучшение моей личной сконцентрированности и организованности. И понял, что это никакой не исторический рудимент. Теперь я понимаю своих коллег с бумажными ежедневниками.

Хотя от электронных ежедневников я не отказался, и продолжаю пользоваться Open Source приложениями:

https://github.com/orgzly-revived/orgzly-android-revived (как заядлый емаксоид в прошлом)

и

https://github.com/tasks/tasks

Оба приложения доступны на F-Droid.

[UPDATE]: Тут подвернулось под руку еще одно неплохое Open Source приложение:
https://github.com/johannesjo/super-productivity/

Я, конечно, подозревал, что у Яндекса страдает морально-деловая сторона, но чтоб Яндекс.Такси было способно дважды чистосердечно признаться в том, что оно вытерает ноги о ст.10 ФЗ N 2300-1 о защите прав потребителей, я не предполагал. Не предполагал, потому что это происходит в стране, которая берет на себя смелость позиционировать себя как защитника правовых и высоконравственных ценностей на внешне-политической арене. Яндекс даже не пытается создать видимость уважения к Закону и к законным правам своих клиентов.

В чем суть. Саппорт Яндекса признал дважды, что Яндекс.Такси самовольно и беспричинно выставляет произвольную стоимость за уже фактически оказанную услугу, которая никак не коррелирует с той стоимостью, которая в соответствии со ст.10 ФЗ N 2300-1 была оглашена перед оказанием услуг, с целью обеспечения клиенту возможности правильного выбора. А чтобы окончательно запутать клиента, стоимость услуги отображается раздельно от стоимости ожидания лишь однократно при завершении заказа. В истории заказов стоимость услуги и ожидания раздельно уже не отображается, что усложняет клиенту возможность защиты своих прав. И именно этим пользуется саппорт, пытаясь ввести клиента в заблуждение о стоимости услуг ожидания.

По моему сугубо личному мнению, это даже не столько нарушение ст. 10 ФЗN 2300-1, сколько завладение чужими средствами обманным путем, что имеет признаки уголовного преступления, предусмотренного ст. 159 УК РФ.

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

В общем, будьте внимательны при использовании услуг Яндекса.

Многие думают, что конкуренция существет для достижения качества. Это не совсем так. Конкуренция существует для достижения разнообразия форм хозяйствования в условиях изменяемости рыночных условий. Где сейчас компания Кодак по производству фотоаппаратов на основе засветки серебра? А где был Гугл когда многие ходили с кнопочными телефонами Nokia?

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

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

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

Я уже не говорю про целый клубок сопутствующих эффектов, таких как:
- "Эффект Даннинга — Крюгера"
- "Склонность к подтверждению своей точки зрения"
- "Психологическая защита"
- "Закон иррационального усиления"
- "Систематическая ошибка выжившего"
- "Кривая забывания"
- "Кривая обучаемости"
- "Эффект края (память)"
- "Эффект недавнего"

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

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

Коллеги, хочу обратить внимание на приложение
https://github.com/johannesjo/super-productivity/ в качестве цифрового персонального ежедневника (если кому удобней цифровые).

1. Open Source
2. Работает и на Android (доступен в т.ч. на F-Droid), и на iPhone, и на Microsoft, и на Linux, и в брузере.
3. Можно использовать и как Task Manager, и как каледарь. Поддержка рекуррентных событий по RFC 5545.
4. Kanban board.
5. Матрица Эйзенхауэра.
6. Time Tracker.
7. Pomodoro
8. Интеграция с целой кучей систем управления проектами (Jira, Redmine, GitHub, GitLab, CalDAV, Open Project, Gitea etc.)
9. Интеграция с целой кучей календарей (Google Calendar, Outlook, iCal etc.)

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

Browser plugin for PERT estimates in JIRA:
https://github.com/aligent/pert-with-wings

Хорош тем, что не нужно просить администратора Jira устанавливать Jira plugin вроде этого:
https://marketplace.atlassian.com/apps/1218473/pert-calculator

Может кому-нибудь пригодится еще и online калькулятор:
https://goodcalculators.com/pert-calculator/

См. также
- https://www.tgoop.com/emacsway_log/916
- https://www.tgoop.com/emacsway_log/1101

Вдруг кому пригодится. На главной странице сайта org-mode https://orgmode.org/ перечислены решения, с помощью которых можно использовать org-mode на мобильных устройствах:
Android : Orgzly Revived, Orgro, Org Note
iOS : MobileOrg, Orgro
Web : Organice (progressive web app), Org Note

С какими трудностями я обычно сталкивался в своей практике при реализации Specification Pattern?

1. Расслоение, если мы хотим применять его как для фильтрации объектов в оперативной памяти, так и в БД. Обычно эта проблема решается через Expression Tree, но в Golang такой опции нет, что, правда, легко обходится самодельным синтаксическим деревом.

При этом возникает вопрос о том, должна ли логика предиката реализовываться в виде интерпретатора на основе Expression Tree или дублироваться хардкодно?

2. Когда агрегаты храняться в JSONB колонке БД, обычно проблем не возникает, и мы можем применить коробочные реализации JSONPath.

Трудности возникают когда сущности агрегата хранятся в отдельных табличках без использования JSONB.

В частности, структура таблиц и структура агрегата нередко отличаются. Например, агрегат часто использует композитные первичные ключи и композитные ValueObjects. Это означает, что синтаксическое дерево для предиката агрегата будет отличаться от синтаксического дерева для запроса в БД. Т.е. просто так "коробку" прикрутить не получится. И мне известны только единичные специалисты, обладающие достаточной квалификацией, чтобы написать код трансформации одного дерева в другое.

3. Большинство коробочных интерпретаторов для Expression Tree, которые можно приспособить для реализации Specification Pattern, умеют оперировать только примитивными типами данных, и без существенной доработки не умеют совершать операции над ValueObjects, особенно, если язык программирования не поддерживает перегрузку операторов.

4. Инкапсуляция агрегата. Это отдельный большой вопрос, который часто обсуждается в отрасли и уже не раз обсуждался мной. Чаще всего для извлечения защищенного состояния агрегата используются:
1. Общие области видимости (как в Golang) или дружественные классы (C++).
2. Mediator Pattern (описан в красной книге Vaughn Vernon).
3. Рефлексия (нередко используется в коробочных решениях, особенно в ORM).
4. Memento Pattern, хотя и часто называют, но ошибочно, если внимательно разобраться.

5. Самая любимая моя проблема - это предикаты к атрибутам коллекции сущностей агрегата с использованием Expression Tree.

Как выразить в Expression Tree следующее условие:
хотя бы одна из сущностей коллекции агрегата имеет значение "x" атрибута "a" и значение "y" атрибута "b", или хотя бы одна из сущностей той же коллекции имеет значение "j" атрибута "с"?

Ничего не получится, если напишем нечто подобное:
agg.ent[*].a == x && agg.ent[*].b == y && agg.ent[*].c == j

Кажется, такое ни одна коробка не умеет, за исключением операторов wildcard "*" и локального елемента "@" в JSONPath. Собственно, оттуда я и перенял решение:
agg.ent[*] ? (@.a == x && @.b == y) || agg.ent[*].c == j

Если скомпилировать это выражение в SQL запрос к обычным реляционным табличкам (без JSONB), то получится два JOIN.

Не знаю, можно ли выразить нечто подобное с помощью LINQ в C# (если да, то сообщите, пожалуйста, в комментарии).

Когда должно вернуть true следующее выражение:
agg.ent1[*].a == agg.ent2[*].a ?
Когда совпадает хотя бы один элемент в обоих подмножествах, или когда оба подмножества эквиваленты?

Нет ничего сложного в реализации Specification Patrern on Expression Tree, если обладать достаточным опытом и квалификацией. Реализация занимает всего несколько сотен строк кода.

Сложно найти/подготовить такого специалиста в команду.