Вот хорошая книга про конфронтации и споры.

https://www.ozon.ru/product/dzhedayskie-tehniki-konstruktivnogo-obshcheniya-orlov-aleksandr-elektronnaya-audiokniga-917253665/?asb=Be%252FFUBK71EHhLQk04ZAlECN22i2r54PLYZjRAV%252FwRMo%253D&asb2=b3hGw0AlGeI7bXnX6OqomduBi5-hpqViN4jaN8zk1g--XB946T70msRJKBytJvo9&avtc=1&avte=2&avts=1696928187&keywords=%D0%B4%D0%B6%D0%B5%D0%B4%D0%B0%D0%B9%D1%81%D0%BA%D0%B8%D0%B5+%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D0%BA%D0%B8

Ну и еще ряд сообщений, начиная отсюда (обсуждали ранее):
https://news.1rj.ru/str/emacsway_log/450

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

Именно об этом гласит один из 12 принципов Agile-manifesto:
💬 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

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

Основных участников обсуждения я знаю уже более 4 лет, и они существенно повлияли на становление меня как специалиста.

Отдельно хочу выделить Дениса Бескова - человека с уникальной грамотностью. Его проницательность всегда заставляет меня задуматься (иногда не сразу). А ведь было бы так удобно и комфортно считать себя "самым-самым" и избавиться от всех раздражителей своей зоны комфорта, заклеймив их. Это путь деградации. И именно об этом был мой пост.

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

Искренне поздравляю @vladik_kh !!! 🎉🍾
https://learning.oreilly.com/library/view/balancing-coupling-in/9780137353514/

Монументальный, титанический труд, который под силу только Настоящему Титану! Дейкстра современности!

Книга уже признана такими авторитетами, как Gregor Hohpe, который в восторге от неё!

Это даже не луч света в темном царстве спагетти-кода. Это настоящий прожектор путеводного маяка в океане архитектуры!

Это не самая удачная запись. Здесь лучше:

https://youtu.be/6indW7BSGZI?si=EZvt-9PjkaQjsWzg

Запись расширенной версии доклада есть с ddd europe 2023

На сайте EventStoreDB нашел транскрипт легендарного выступления Грега Янга, случившегося 10 лет назад. В виде текста оно воспринимается немного иначе. Чем-то похоже на известный 50-страничный CQRS Documents

Знаете что меня удивляет? Несмотря на обилие инфы вокруг этой темы, в ней, почему-то, всегда остается возможность добавить еще что-то новое. В том-же блоге Event Store ряд актуальных заметок, но и не только. В общем - залезаем все глубже в кроличью нору

В материалах TheOpenGroup опубликованы не только файл с описанием и archimate-моделью учебного кейса ArchiSurance Case Study, но и сформированная при помощи Archi web-версия модели для этого кейса(правда немного кривая, как и сам Model Exchange File примера)

Начинать смотреть вот с этой вкладки: https://pubs.opengroup.org/architecture/case-study-models/archisurance-html/?view=id-45418

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

Если почитать внимательно оригинальную статью "Pattern: Backends For Frontends" by Sam Newman, то в главе "General Perimeter Concerns" можно заметить, что он рекомендует размещать BFF после "generic perimeter concerns, such as authentication/authorisation or request logging". Т.е. после "Gateway Offloading pattern".

Проблема в том, что конструктивно "Gateway Offloading pattern" и "Gateway Routing pattern" реализуются на практике одним и тем же решением, например, KrakenD.

В свою очередь, "Gateway Routing pattern" решает проблему "the client must be updated when services are added or removed."

Vlad Khononov возлагает на api-gateway еще и функции "Anticorruption layer":
💬 "Anticorruption layers implemented using an API gateway can be consumed by multiple downstream bounded contexts." (для frontend это особенный вопрос).

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

Другой аргумент заключается в том, что BFF нуждается в агрегации, а не наоборот.

Ну и в таком случае он не сможет решать проблему "causing the backend to become a bottleneck in the development process."

Выгдядит так, что BFF должен располагаться, всё-таки, перед api-gateway. Какие существуют еще аргументы или контр-аргументы?

Как мне удалось выяснить, я не первый кто об этом задумался. KrakenD потому и использует декларативное описание в формате JSON, чтобы он мог выполнять в т.ч. и функции BFF силами команды разработки клиентского приложения.

💬 Desktop and mobile interfaces usually compete in requirements, and the backends keep growing to fit both types of usage. Every frontend team will work in different data views to display the content, and the backend team becomes a bottleneck as it must fulfill the frontend team’s needs. In many cases, the same type of information (or view) will require different response formats and response errors for each consumer, making your backend developers spend a lot of time developing this logic. And many meetings and time making the different frontend dev teams get on the contract agreement!

# How the BFF works

KrakenD implements the BFF pattern with aggregation, allowing your frontend teams to define precisely the information you want to retrieve from the different services and how to deal with the errors.

The client receives:
- Exactly the data it needs, and no more.
- The information for a use case is taken from a single call
- Aggregated information containing all involved services
- Optionally, stub static data when there’s missing information
- Separation of concerns
- Decoupling: Do not have to worry very much about the backend changing or evolving

-- https://www.krakend.io/docs/design/backend-for-frontend/

В процессе обсуждения в чате канала ко мне в библиотеку попала новая книга "Джедайские техники конструктивного общения" Александра Орлова.

Там была одна метафора, которая заставила меня задуматься:

💬 Что делает кирпичную стену прочной? Идеальная геометрия каждого кирпичика или смесь, скрепляющая их между собой? Если вы видели, как делают кирпичную кладку, то легко можете представить, как получается ровная и прочная стена, несмотря на далекую от идеала точность изготовления отдельных кирпичей.

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

@BorisRomanov развидел то, что упустил я - важна не стена, а фундамент! Именно о фундаменте говорится здесь:

💬 "Важно не объединение людей само по себе, а те принципы, на которых оно основано."

Автором этого утверждения является Фидель Кастро. А он умел создавать высокоэффективные команды.

Когда его группа (вместе с Эрнесто Че Геварой) из 82 голодных, изнеможённых человек добралась вброд до берегов Кубы, - их поджидали 35000 вооружённых солдат, танки, 15 судов береговой охраны, 10 военных кораблей, 78 истребителей и транспортных самолётов. И они победили. Они осуществили одно из самых немыслимых изменений в истории человечества.

На собственном примере они доказали слова "Шарль де Голль":
💬 "Исторический фатализм существует для трусов. Смелость и счастливый случай не раз меняли ход событий. Этому учит нас история. Бывают моменты, когда воля нескольких человек сокрушает все препятствия и открывает новые дороги".

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

Это точно не первая статья, искал как-то для митапа инфу.
На несколько месяцев раньше статья Phil Calçado, про его опыт в SoundCloud, где вводится сам термин BFF. По крайней мере я не нашёл более ранних упоминаний. https://philcalcado.com/2015/09/18/the_back_end_for_front_end_pattern_bff.html

А за 3 года до этого (2012) статья Netflix, где без введения термина BFF тем не менее очень подробно разбираются предпосылки к этому паттерну и немного об их реализации. Вполне возможно, что Netflix, с их ~800 типами клиентов, были действительно первыми, кто реально столкнулся с такой проблемой в масштабах.
https://netflixtechblog.com/embracing-the-differences-inside-the-netflix-api-redesign-15fd8b3dc49d

Причина, по которой Microsoft Reference Application eShopOnContainers выбрал Envoy (взамен Ocelot) в качестве api-gateway, заключается в поддержке gRPC и WebSocket:

The reference microservice application eShopOnContainers is currently using features provided by Envoy to implement the API Gateway instead of the earlier referenced Ocelot. We made this design choice because of Envoy's built-in support for the WebSocket protocol, required by the new gRPC inter-service communications implemented in eShopOnContainers.
-- https://learn.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/implement-api-gateways-with-ocelot

Как я выяснил, KrakenD поддерживает их только в Enterprise версии.

Из полностью свободных аналогов с поддержкой gRPC и WebSocket выделяются Envoy и Apisix.

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

Коллеги, если кто-то ищет проверенного высококвалифицированного специалиста по DDD, микросервисам, Clean Architecture на Golang - обращайтесь ко мне в личку, пока кандидатура не ушла. Имеет успешный практический опыт лида, программиста, архитектора и глубокую теоретическую подготовку. Его не нужно обучать и после него не нужно переделывать.

Единственное ограничение - работа из-за границы, платежи на зарубежный счет. Не налоговый резидент (но гражданин) РФ.

Не дешевый, но очень выгодный. Ручаюсь.

Идет мужик по лесу, смотрит - другой мужик лес рубит топором.
- Что делаешь?
- Лес рублю.
- Бензопила же рядом лежит. Возьми её - быстрее будет.
- Я не умею ею пользоваться.
- Инструкция лежит же рядом. Возьми, прочитай.
- Мне некогда - лес рубить надо.

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

В процессе программирования программист вводит символы с клавиатуры не более 10% времени (зачастую - не более 1% времени). Остальное время он читает существующий код и борется со сложностью.

Плохой код пишется одним программистом, однократно, не более 10% времени. А читается он всеми программистами команды, многократно, постоянно, более 90% времени программирования. Т.е. однократно написанный одним программистом плохой код будет замедлять всю команду более 90% её времени.

Таким образом, фраза "некогда писать правильно" является самообманом. Если у команды медленный темп разработки, то он более чем на 90% времени вызван медленным чтением и затрудненным пониманием написанного ранее кода. Именно поэтому скорость разработки деградирует обычно в геометрической прогрессии.

Самообманом является и фраза "потом исправим". Как сказал Randy Shoup, если у вас нет времени сделать это правильно, то с чего вы взяли, что у вас будет время сделать это дважды? Тем более, что потом скорость разработки будет ниже, а напряжение - выше.

Количество введенных символов слабо коррелирует со скоростью разработки. Например, ребята, увлекающиеся спортивным прохождением кат по программированию, заметили, что используя TDD они пишут в разы больше объем кода, но проходят каты процентов на 10% быстрее, чем без ТДД.

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

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

Я вспоминаю, когда я начал работать с литературой по Software Design, то мой код начал существенно преображаться. Мой старый код вызывал у меня стыд. Я взял паузу в программировании Open Source проектов и засел за книжки. Я понимал, что лучше "прочесть инструкцию к бензопиле", нежели продолжать "рубить топором" то, что потом все-равно переделывать.

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

Хороший код отличается простотой, и выполняет главный императив разработки - управление сложностью. Но хороший код не спасает от еще одной сложности, про которую недавно написал @BorisRomanov (начиная отсюда). На эту же тему писал Егор Толстой и даже сам E. Dijkstra:

💬 "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)

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

Труднее обстоит дело, когда вы не можете передавать знания команде личным примером, например, на позиции лида или архитектора. Для менеджмента ваши "инструкции к бензопиле" - просто отвлекание команды "от рубки леса". Возникает дилемма: спасать менеджмент от самого себя, вопреки его воле, понимая, что он никогда это не оценит, или же проявить внешний конформизм, осознавая, что
💬 "Те компании, которые не осознают, что знания являются средством производства более важным, чем земля, труд или капитал, постепенно умрут и никогда не поймут, что их погубило."
—Ларри Прусак

Хотелось порассуждать дальше, но закончилось место. Ладно, потом...