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

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

Есть еще один важный момент - мои идеи коллективно-распределенного блокнота, сформированные ещё в 2021 году, наконец-то проросли и начали давать результат, которым я впечатлен. Хочется верить в то, что этот результат продолжит развиваться стабильно и длительно.

💬 "Лидеры умеют чередовать глобус с микроскопом. Они мыслят масштабно, но избирательно уходят в детали, когда рассматривают ключевые моменты."

Подсмотрено здесь:
https://www.tgoop.com/ClubM/1447

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

Ответ на вопрос о том, должен ли архитектор уметь погружаться в код, тоже зависит, как мне кажется, от того, хочет ли он быть лидером или просто рисовать диаграммы:
https://youtu.be/31qcPwAv8Zw

Великолепная статья от Kent Beck для тех компаний, которые трекают активности своих разработчиков:
https://tidyfirst.substack.com/p/measuring-developer-productivity-440

Product vs. Project explained:
https://www.youtube.com/watch?v=EhtsPAdYOds

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

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

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

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

Отсюда вывод - в небольших компаниях больше шансов быть справедливо оцененным.

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

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

Жестоко и честно. Ни подкупить, ни обмануть.

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

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

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

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

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

Но прежде я хочу дополнить предыдущий пост двумя тезисами.

1. Помните некогда широко известную корпорацию Kodak? А Nokia? MySpace? Blackberry? Где они сегодня?

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

2. Пресмыкательство отличается от приспособленности именно утратой субъектности.

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

Первое направлено на обретение независимости от внешних субъектов, второе - на усугубление зависимости.

Разница примерно такая же, как между "служить" и "прислуживать".

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

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

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

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

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

Таким образом, если попытаться спроецировать этот механизм на архитектуру, то должны присутствовать следующие составляющие:

1) неопределенность внешней среды (контекста);
2) генерация разнообразия форм решения (где решение - это совокупность его элементов (как и комбинация ген));
3) селекция - истребление слабо приспособленных к текущим условиям окружающей среды решений;

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

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

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

По этой же причине, рыночная экономика, в основе которой лежит adaptation (в отличии от плановой экономики), немыслима без кризисов и войн - чтобы истреблять слабо приспособленные формы хозяйствования. Конкуренция генерирует новые формы хозяйствования, а кризисы их сокращают. Т.е. механизм экономической эволюции по своей сути мало чем отличается от механизма биологической эволюции.

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

И тут мы подошли к ключевой цели Evolutionary Architecture.

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

Что такое вариант архитектурного решения? Это конфигурация комбинации элементов системы. Что такое система? Это математическая свертка архитектурных решений. Именно поэтому, ADR документирует системный инкремент (т.е. изменение системы), а не саму систему.

💬 A system is never the sum of its parts. It is the product of the interactions of its parts.
-- Dr. Russel Ackoff

Мы подошли к тому, чтобы понять идею автора Evolutionary Architecture. Еще раз выделю главное:

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

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

Теперь обратимся к автору Evolutionary Architecture:

💬 Going back to our biological metaphor, evolutionary is about the process of having a system that is fit for purpose and can survive the everchanging environment in which it operates. Systems may have individual adaptations, but as architects, we should care about the overall evolvable system.

Ключевые моменты (еще раз):
1. Изменчивость среды функционирования.
2. Выживаемость.
3. Роль архитектора.

Вот с ролью архитектора не очень пока понятно. Идем дальше:

💬 The authors borrow a concept from evolutionary computing called “fitness functions,” used in genetic
algorithm design to define success. Evolutionary computing includes a
number of mechanisms that allow a solution to gradually emerge via small changes in each generation of the software. At each generation of the solution, the engineer assesses the current state: Is it closer to or further away from the ultimate goal? For example, when using a genetic algorithm to optimize wing design, the fitness function assess wind resistance, weight, air flow, and other characteristics desirable to good wing design. Architects define a fitness function to explain what better is and to help measure when the goal is met. In software, fitness functions check that developers preserve important architectural characteristics.
We use this concept to define architectural fitness functions:

An architectural fitness function provides an objective integrity assessment of some architectural characteristic(s).

Ключевые моменты:

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

2. Поколение системы (текущая версия системы) основана как на наследовании структурной комбинации предыдущего поколения, так и на её изменении.

3. Инженер оценивает текущий уровень приспособленности системы. Сам термин fitness означает приспособленность, соответствие.

Важный момент - не просто удовлетворяет требованиям, а именно "Is it closer to or further away from the ultimate goal", т.е. является ли он лучше или хуже. Происходит сравнение двух вариантов. Именно этот момент многие не понимают, и это ставит крест на идее эволюции архитектуры.

Многие считают, что назначение fitness functions сводится к тому, чтобы просто протестировать новую версию системы, чтоб она просто прошла заданный набор тестовых кейсов. Это не верно. Их назначение - оценить, насколько лучше или хуже стала новая версия системы. В системе изменилась конфигурация комбинации её элементов (подобно комбинации ген поколения). Зачача архитектора - хищническая, и заключается она в том, чтоб сократить количество вариантов "генетических комбинаций". Вспоминаем, что архитектурное решение есть результат сокращения количества возможных вариантов. Архитектор решает, какой вариант структурной комбинации системы должен умереть и не должен больше воспроизводиться (репродуцироваться) в новых поколениях системы. Происходит то, что называется в биологии "селекция". В результате истребления наименее приспособленного варианта происходит то, что в приведенной цитате называется "to optimize".

После этого решение можно зафиксировать, изменив параметры fitness function на более строгие, соответствующие достигнутым текущей комбинации системы. Таким образом происходит эволюция системы, т.е. повышение уровня соответствия системы текущим условиям. Именно об этом говорит автор:

💬 The systemwide fitness function is crucial for an architecture to be evolutionary, as we need some basis to allow architects to compare and evaluate architectural characteristics against one another. Unlike the more directed fitness functions, architects will likely never try to “evaluate” this systemwide fitness function. Rather, it provides guidelines for prioritizing decisions about the architecture in the future.

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

Вся эта сложность нужна потому, что

💬 We can also think about the systemwide fitness function as a collection of fitness functions with each function corresponding to one or more dimensions of the architecture. Using a systemwide fitness function aids our understanding of necessary tradeoffs when individual elements of the fitness function conflict with each other.

As is common with multifunction optimization problems, we might find it impossible to optimize all values simultaneously, forcing us to make choices. For example, in the case of architectural fitness functions, issues like performance might conflict with security due to the cost of encryption. This is a classic example of the bane of architects everywhere — the tradeoff.

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

Возвращаемся к статье https://www.thoughtworks.com/en-gb/insights/articles/fitness-function-driven-development

Затрудняюсь ответить, что больше от этой статьи, пользы или вреда. Статья уволит в сторону от ключевой идеи fitness function. Авторы воспринимают TDD как способ тестирования, в то время как TDD является способом проектирования. И уж TDD точно никогда не предназначался для повышения "test coverage".

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

Несмотря на то, что статья правильно цитирует назначение fitness function:

💬 Fitness functions describe how close an architecture is to achieving an architectural aim.

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

💬 As a result, every new service or piece of software is developed in a way that passes the fitness functions and supports the architectural qualities we value.

А здесь и того хуже - измеряется технический долг, что свидетельствует о деградации решения (а значит, эволюция не работает), и непонятно зачем за уши притянуто качество кода:

💬 First, fitness function-driven development objectively measures technical debt and drives code quality.

Снова речь идет не о селекции архитектурных решений, а о достаточности прохождения тестовых кейсов:

💬 teams are quickly notified of the changes, able to react quickly, and have objective tests to validate conformance.

💬 With architecture goals expressed as code, conformance tests can be incorporated in build pipelines to monitor alignment with the architectural “-ilities” that are most critical.

Сравним это с утверждением автора оригинала:

💬 to allow architects to compare and evaluate architectural characteristics against one another.

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

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

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

Коллеги, если проголосуете - буду рад, но сторизы не обещаю 🙂)

Еще один интересный тезис из книги, где evolutionary architecture сравнивается в селекцией породистых собак:

💬 While software architects are interested in exploring evolutionary architectures, we aren’t attempting to model biological evolution. Theoretically, we could build an architecture that randomly changed one of its bits (mutation) and redeployed itself. After a few million years, we would likely have a very interesting architecture. However, we don’t have millions of years to wait.

We want our architecture to evolve in a guided way, so we place constraints on different aspects of the architecture to reign in undesirable evolutionary directions. A good example is dog breeding: By selecting the characteristics we want, we can create a vast number of different shaped canines in a relatively short amount of time.

Что интересно в этой фразе? А интересно здесь то, что в кинологии:

💬 По мере возникновения исторических изменений в породе в стандарт могут вносится корректировки.

💬 Стандарт периодически пересматривают и изменяют, что обеспечивает прогресс породы

-- Википедия.

Прошу простить за адресацию к Википедии - всё-таки я не кинолог и не зоотехник 🙂) Последняя цитата взята из http://www.kgau.ru/distance/zif_03/razvedenie-110401/07_01.html - вроде заслуживает доверия.

Ключевой момент - изменения в стандарт вносятся не только по мере выявления желаемых свойств породы, но и по мере достижения самих изменений в породе.

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

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

Вебининар по EventSoursing.

Коллеги, помните, я писал про этого парня @schetinnikov ? В этот четверг он проведет вебинар про Event Sourcing, и расскажет, как внедряли его на практике, какие были подводные камни, какой результат был достигнут. Подробности здесь:
https://www.tgoop.com/ru_arc/278

P.S.: прошу поддержать репостом

P.S.S.: исправил ссылку на событие.

Коллеги, что думаете об этом утверждении Дональда Трампа?

Статья про доменную модель, о которой я говорил, опубликована:
https://dckms.github.io/system-architecture/stanislav.bolsun/it/ddd/domain-model/domain-model-definition.html

Глубоко признателен @StanislavBolsun за авторство и за проделанный труд.

Есть идеи организовать по материалам статьи вебинар с автором.