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

На почве предыдущего поста мне вспомнились слова Никлауса Вирта:

💬 "Богатство функциональных возможностей во многих современных языках - это действительно проблема сама по себе, а не решение других проблем. Избыток возможностей - это еще одно следствие веры многих программистов в то, что ценность языка пропорциональна количеству этих возможностей (как я это называю- это вера в "колокольчики и свистки"). Однако, мы знаем, что будет лучше, если каждое базисное понятие представляется единственной, специально для этого предназначенной конструкцией. Это не только сокращает усилия по изучению языка, но и сокращает размер его описания, что, в свою очередь, помогает избежать несогласованности и неправильного понимания. Поддержание языка максимально простым и регулярным всегда было приоритетом в моей работе: описание Pascal занимало около 50 страниц, Modula - около 40, а Oberon - и вовсе 16. И я рассматриваю эту тенденцию как прогрессивную. Истинная ценность языков программирования зависит от качества и практичности их абстракций. Пример - абстракция, называемая "число" или абстракция "логическая величина", замещающая конкретную строку битов.

Ценность такого рода абстракции основывается на ее целостности. В случае чисел должны быть применяемы только арифметические операции, независимо от того факта, что логические операции, в принципе, также могут быть применимы к битовым строкам, представляющим числа."
—"О культуре разработки ПО" / Никлаус Вирт

Кстати, вспомнилось, что Golang унаследовал идеи Oberon.

#Simplicity

Если вы задумываетесь о качестве процессов в вашем проекте, но не знаете с чего начать, то настоятельно порекомендуем ознакомиться с Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology.

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

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

Eric Evans дает интересное определение Constantine's Law нетехническим языком:

💬 "МОДУЛИ дают возможность посмотреть на модель с разных сторон:
во-первых, можно изучить подроб­ности устройства модуля, не вникая в сложное целое;
во-вторых, удобно рассматривать взаимоотношения между модулями, не вдаваясь в детали их внутреннего устройства.

<...>

То, что при делении на модули должна соблюдаться низкая внешняя зависимость
(low coupling) при высокой внутренней связности (high cohesion)- это общие слова. Определения зависимости и связности грешат уклоном в чисто технические, количест­венные критерии, по которым их якобы можно измерить, подсчитав количество ассо­циаций и взаимодействий. Но это не просто механические характеристики подразде­ления кода на модули, а идейные концепции. Человек не может одновременно удер­живать в уме слишком много предметов (отсюда низкая внешняя зависимость). А плохо связанные между собой фрагменты информации так же трудно понять, как неструктурированную "кашу" из идей (отсюда высокая внутренняя связность).

MODULES give people two views of the model:
They can look at detail within a MODULE without being overwhelmed by the whole, or they can look at relationships between MODULES in views that exclude interior detail.

<...>

It is a truism that there should be low coupling between MODULES and high cohesion
within them. Explanations of coupling and cohesion tend to make them sound like technical metrics, to be judged mechanically based on the distributions of associations and interactions. Yet it isn't just code being divided into MODULES, but concepts. There is a limit to how many things a person can think about at once (hence low coupling). Incoherent fragments of ideas are as hard to understand as an undifferentiated soup of ideas (hence high cohesion)."
-- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans, перевод В.Л. Бродового

#SoftwareDesign

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

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

Chat Digest

💬 "A Hybrid Software Architecture Evaluation Method for FDD - An Agile Process Model"
- https://t.me/ru_arc_chat/1325

💬 Менеджеры топят за Agile без архитектуры. Что делать?
- https://t.me/ru_arc_chat/1326

💬 Awesome workflow engines:
- https://github.com/meirwah/awesome-workflow-engines

💬 Steve McConnell о DDD:
- https://t.me/ru_arc_chat/1362

💬 "Самовозникающий социальный паттерн" системной динамики - "Стремление к худшему":
https://t.me/ru_arc_chat/1392

💬 Энтропия системы имеет склонность к росту - Gregor Hohpe:
- https://t.me/ru_arc_chat/1395
- https://t.me/ru_arc_chat/1391

💬 Цикл сообщений о роли Semantic Coupling:
- https://t.me/ru_arc_chat/1411

💬 Типы Coupling:
- https://t.me/ru_arc_chat/1413

💬 Оригинальная книга "Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design" by Edward Y ourdon and Larry L. Constantine
- https://t.me/ru_arc_chat/1434

💬 Что такое Coupling от Larry Constantine:
- https://t.me/ru_arc_chat/1441

💬 DevOps модели:
- https://t.me/ru_arc_chat/1488

💬 Продакт не выделяет ресурсов на устранение техдолга. Что делать?
- https://t.me/ru_arc_chat/1490

💬 Когда делать рефакторинг:
- https://t.me/ru_arc_chat/1508

💬 Как устранять техдолг?
- https://t.me/ru_arc_chat/1509
- https://t.me/ru_arc_chat/1510

💬 Влиятельный инструмент на менеджмент:
- https://t.me/ru_arc_chat/1512

💬 Код - это рабочее место программиста и условия труда:
- https://t.me/ru_arc_chat/1515
- https://t.me/ru_arc_chat/1527

💬 Почему придумали Story Point?
- https://t.me/ru_arc_chat/1518

💬 Кто отвечает за качество кода, Продакт или Команда?
- https://t.me/ru_arc_chat/1524

💬 Заложить работу с техдолгом в оценку задачи:
- https://t.me/ru_arc_chat/1548
- https://t.me/ru_arc_chat/1552
- https://t.me/ru_arc_chat/1567
- https://t.me/ru_arc_chat/1573

💬 Является ли Продакт руководителем разработки?
- https://t.me/ru_arc_chat/1549

💬 Усугубить кризис и решить техдолг под шумок:
- https://t.me/ru_arc_chat/1564

💬 Что такое Transparency? Означает ли это спрашивать разрешения у Продакта на устранение техдолга?
- https://t.me/ru_arc_chat/1568

💬 Можно ли удовлетворить интересы всех стейкхолдеров? Как находить сбалансированные решения и взаимокомпенсировать когнитивные искажения сторон. ATAM в Agile?
- https://t.me/ru_arc_chat/1569

💬 "Синдром второй системы" народным языком:
- https://t.me/ru_arc_chat/1571

💬 "Правило трех ударов" народным языком:
- https://t.me/ru_arc_chat/1616
- https://t.me/ru_arc_chat/1691

💬 ITIL Foundation, практика Problem Management
- https://t.me/ru_arc_chat/1650

💬 Крутое разъяснение простым языком про обратную корреляцию требований:
- https://t.me/ru_arc_chat/1669

💬 Крутое разъяснение о том, как относиться к проблемам:
- https://t.me/ru_arc_chat/1678

#ChatDigest

Иногда кажется, что дискуссия ходит по кругу, оппоненты озвучивают одни и те же тезисы и аргументы, но спор продолжается и не приносит ни пользы, ни удовлетворения. Хочется только в стиле Задорного сказать про другую сторону "Ну тупыыые"...

Было у вас такое? У меня точно было много раз. Иной раз оптимальной стратегией будет просто не вступать в споры – все равно никто не готов менять свою позицию.

Но если вы все таки готовы менять свои убеждения и спор для вас это не прокачка ЧСВ, то рекомендую попробовать приемы уличной эпистемологии https://streetepistemology.ru/vvedenie-v-ue.

Помните, что цель дискуссии – не переубедить собеседника, а прийти к верному мнению)

Превосходная статья о том, как недостаточная дивергентная фаза исследований и ограниченный охват опыта молодых авторов чреваты опасностью скатывания в когнитивное искажение "Straw man":

- "Advocate, educator, and authorial stance" by Martin Fowler.

Не так давно в одном из чатов я обращал внимание на распространённость этого явления в технических пабликах.

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

💬 "The reason the author wants to write about this technique is because they’ve found it worked really well, and believe that their readers can improve their software development experience by using it.
<...>
In these situations it's too easy to debate a straw man version of the alternative technique.
<...>
The advocate wants the reader to agree with them, they succeed when the reader uses the technique that’s being advocated.
<...>
Authors often make straw men of the alternatives in good faith because they have encountered them done poorly or in the wrong context. Such advocacy can often undermine its own position by not fully considering the advantages of the alternative technique. If a reader spots this, then they start to judge the article by the weakness of the arguments against the alternative, rather than focusing on the genuine capabilities of the new technique."

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

На эту тему хорошо выразился Kent Beck - если вы ехали в один город, а приехали в другой, то причем здесь автомобиль?

Эта статья, в свою очередь, ссылается на другую монументальную статью - "Cargo Cult Software Engineering" by Steve McConnell.

На что я обратил внимание, так это на то, что коммуникативная психология обретает все большую практическую ценность в нашей технической отрасли. А то, что об этом все чаще стали говорить такие личности, как Gregor Hohpe, Martin Fowler, Neal Ford и др., наводит на мысль о том, что область знаний достигла определенного уровня обобщения и систематизации, и уперлась в когнитивные искажения, препятствующие дальнейшему развитию отрасли. Кстати, решение этой проблемы является одной из целей нашего объединения.

#SoftSkills #Psychology

Если вы затрудняетесь объяснить менеджменту что такое технический долг и легаси, то вот неплохой пример от нетехнаря (и в этом заключается ценность статьи, т.к. она написана простым языком, понятным нетехнарю).
https://vitalyfilatov.ru/all/techdebt-and-legacy/

Хорошая подборка моделей согласованности.

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


https://jepsen.io/consistency

Продолжается прием заявок на доклады конференции по архитектуре IT-решений ArchDays 2022!

В этом году мы возвращаемся в офлайн!
Конференция пройдет 21 октября в Москве + Online-трансляция.

Основные тематики конференции:
1. Процессы проектирования
2. Инструменты проектирования
3. Практики проектирования
4. Обучение архитектуре/развитие в архитектора
5. Soft skills
6. Кейсы

Всего в программе будет около 30 докладов и 4 очных воркшопов.

Подать заявку на выступление: https://archdays.ru/#speaker

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

#Goal

Если вдруг кто не знал, последнюю версию "Distributed systems: principles and paradigms" 3d edition (3.03 от 2020 года) by Andrew S. Tanenbaum, Maarten Van Steen можно скачать бесплатно на официальном сайте:

https://www.distributed-systems.net/index.php/books/ds3/

Пусть вас не смущает, что на сайте указан 2017й год. На почту придет книга с редакцией за 2020.

🔷 "Diagramming to Communicate" by Vaughn Vernon
- Статья про UML, EventStorming, способы выражения SAGA в EventStorming, ну и конечно же про разрабатываемый им сервис для моделирования EventStorming https://domorobo.to/ с генерацией кода посредством XOOM Designer.
💬 "Kalele is building the modeling tool DomoRoboto. It hosts seven model types, including EventStorming, DDD Context Maps that are auto-derived from EventStorming models, Topo Architecture (a blend of EventStorming results with Context Maps), Mind Maps, Impact Maps, Specification by Example (BDD), and User Stories."

#DDD #SoftwareArchitecture #EventStorming

🔷 "Event Sourcing: Why Kafka is not suitable as an Event Store" - Don’t believe everything a company or some consultants want to sell you!
by Anton Stöckl - автор проекта go-iddd - Golang DDD CQRS/ES Reference Application

#DDD #CQRS #EventSourcing #SoftwareDesign

Последняя трактовка принципов SOLID by Robert C. Martin от 2022-07-06 (ничего нового, но снижает вероятность ложного восприятия):

💬 "The Single Responsibility Principle (SRP):

Gather together those things that change for the same reasons and at the same times. Separate those things that change for different reasons or at different times."

💬 "The Open-Closed Principle (OCP):

Separate modules that frequently change from modules that change less frequently with a layer of abstraction."

💬 "The Liskov Substitution Principle (LSP):

The implementation of an interface must never violate the contract between that interface and its users."

💬 "The Interface Segregation Principle (ISP):

Don't depend on things you don’t need."

💬 "The Dependency Inversion Principle (DIP):

Lower level policies should depend on higher level policies."

#SoftwareDesign

🔷 Хотя сайт Alistair Cockburn все еще не работоспособен, оригинальная статья "Hexagonal architecture" доступна для просмотра.

Anton Stöckl не так давно опубликовал очередную статью из цикла, посвященного его проекту go-iddd - Golang DDD CQRS/ES Reference Application:
🔷 "Hexagonal Architecture: Structuring a project and the influence of granularity" - About the granularity of ports and adapters and how it influences the code structure.

Предыдущая статья этого цикла, посвященная Hexagonal Architecture:
🔷 "Implementing Domain-Driven Design and Hexagonal Architecture with Go (3)" - Part 3 — How I structure my application according to Hexagonal Architecture aka. Ports&Adapters

#DDD #SoftwareDesign #SoftwareArchitecture

Выступление одного из учередителей нашего Объединения на ArchDays Recap https://www.youtube.com/watch?v=NSN-NXfbEqM

🔷 "Read models in event-sourced systems" by Alexey Zimarev
Статья является частью документации Eventuous.

#DDD #CQRS #EventSourcing #SoftwareDesign

Видео от Mark Richards о том, как формировать собственные знания, имеет особое значение для нашего канала, поскольку пересекается с его целями:

🔷 "Soft Skills: Gaining Technical Breadth" by Mark Richards

#SoftSkills

Есть ли альтернатива Transactional Outbox pattern? В последнее время этот вопрос часто появляется в пабликах.

Говорят, что "Transactional Outbox" под названием "Local Messaging" впервые был опубликован в статье "BASE: An Acid Alternative: In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability" to ACM by ebay architect Dan Pritchett in 2008.

Как говорил Alexey Zimarev:

💬 "если же это первое сообщение в цепочке - то уже есть смысл смотреть на transactional outbox".

Имеется ввиду в случае отсутствия "Front-Door Queue".

Глубокое понимание этой проблемы и способов ее решения дается в главе "10.Messaging Endpoints :: Transactional Client" книги "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions" by Gregor Hohpe, Bobby Woolf.

А также эта тема затрагивается в главе "Chapter 9. Message Endpoints :: Transactional Client/Actor" книги "Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka" by Vaughn Vernon.

В приведенных главах подробно раскрывается утверждение of Alexey Zimarev.

Vaughn Vernon посвящает этой проблеме главу "8 Domain Events :: Spreading the News to Remote Bounded Contexts :: Messaging Infrastructure Consistency" книги "Implementing Domain-Driven Design".

Ссылки по теме:

🔷 "Subscribing to events :: Publishing events through the event bus :: Designing atomicity and resiliency when publishing to the event bus" by Cesar de la Torre, Bill Wagner, Mike Rousos;
🔷 "Subscribing to events :: Resiliently publishing to the event bus" by Cesar de la Torre, Bill Wagner, Mike Rousos;
🔷 "Transactional messaging" by Chris Richardson
🔷 "3.3.7 Transactional messaging" by Chris Richardson
🔷 "The Outbox Pattern" by Kamil Grzybek
🔷 "Achieving reliable dual writes in distributed systems" by Rishabh Gupta

🔷 "Transaction log mining"
🔷 "Transaction log tailing"

💬 "Both a sender and a receiver can be transactional. With a sender, the message isn’t “really” added to the channel until the sender commits the transaction. With a receiver, the message isn’t “really” removed from the channel until the receiver commits the transaction. A sender that uses explicit transactions can be used with a receiver that uses implicit transactions, and vise versa. A single channel might have a combination of implicitly and explicitly transactional senders; it could also have a combination of receivers.

With a transactional receiver, an application can receive a message without actually removing the message from the queue. At this point, if the application crashed, when it recovered, the message would still be on the queue; the message would not be lost. Having received the message, the application can then process it. Once the application is finished with the message and is certain it wants to consume it, the application commits the transaction, which (if successful) removes the message from the channel. At this point, if the application crashed, when it recovered, the message would no longer be on the channel, so the application had better truly be finished with the message.

How does controlling a messaging system’s transactions externally help an application coordinate several tasks? Here’s what the application would do in the scenarios described above:"
-- "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions" by Gregor Hohpe, Bobby Woolf, Chapter "Transactional Client"

#Microservices #DistributedSystems #Integration #DDD

Можно ли изменять несколько агрегатов одной транзакцией? В профессиональной среде существует популярное мнение что нельзя. Этот вопрос затрагивает Vladimir Khorikov в статье "Crossing aggregate boundaries", и говорит, что:

> I hear this guideline a lot as well.

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

Но, ок, а как все-таки обеспечить соблюдение инвариантов в условиях отсутствия поддержки строгой транзакционной согласованности?

Недавно, как раз обсуждал этот вопрос в одной из заметок.

Одним из решений является "Data, context, and interaction (DCI)" (от авторов MVC).
Подробное описание приводится в главе "Chapter 9. Coding it Up: The DCI Architecture" книги "Lean Architecture: for Agile Software Development" 1st edition by James O. Coplien, Gertrud Bjørnvig.
Можно посмотреть на примере Golang-реализации перевода денежных средств с одного счета на другой счет, с использованием DDD & DCI (доступна также python-версия).

Также стоит выделить в этом вопросе интервью "Modeling Uncertainty with Reactive DDD" by Vaughn Vernon reviewed by Thomas Betts, где решение подобных задач возлагается на Process Manager Pattern.

Другие варианты приводятся в заметке.

#DDD #DistributedSystems