Новая книга от Nick Tune: "Architecture Modernization with Strategic Domain-Driven Design"
A Guide for Technology Leaders
https://leanpub.com/arch-modernization-ddd

#DDD #SoftwareDesign #SoftwareArchitecture #Microservices

Новая статья от разработчиков Watermill
"Introducing basic CQRS by refactoring a Go project"
https://threedots.tech/post/basic-cqrs-in-go/

#DDD #Microservices

Уже не ново, но все еще актуально. Просто вспомнил сегодня об этом твите:
https://twitter.com/jbogard/status/1291744769266384899?s=19 .
Автор твита в представлениях не нуждается. eShopOnContainers - тоже.

#DDD #Microservices

Несколько неплохих ссылок по CRDT для начинающих:

- https://github.com/ljwagerfield/crdt
- http://christophermeiklejohn.com/crdt/2014/07/22/readings-in-crdts.html
- https://habr.com/ru/post/418897/

#DistributedSystems #DDD #Microservices

Сколько Martin Kleppmann заработал на своей книге "Designing Data-Intensive Applications" и что ему это стоило, рассказал вчера он сам в своем блоге:
https://martin.kleppmann.com/2020/09/29/is-book-writing-worth-it.html

#DistributedSystems

Именно так выглялит результат обсуждений профессионального сообщеста о том, каким должен быть образ настоящего архитектора 😃:

А это, я так понимаю, - первоисточник и исходный код этой шпаргалки. Коммитил Nick Tune.
EventStorming Glossary & Cheat sheet
https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet

И канонический адрес:
https://ddd-crew.github.io/eventstorming-glossary-cheat-sheet/

#DDD #EventStorming

Свежий пост от Nick Tune на актуальную тему "Self-documenting Architecture"
https://medium.com/nick-tune-tech-strategy-blog/self-documenting-architecture-80c8c2429cb8

#DDD #SoftwareArchitecture

📝 "Отдельные лица приобретают дешевый авторитет, оснастив свою речь жаргоном: они могут проповедовать и выставлять напоказ поверхностные суждения. Но от математиков-профессионалов требуются не их разглагольствования и даже не степень их осведомленности в тех или иных математических вопросах, а готовность применять свои знания и способность реально решать возникающие на практике математические задачи. Короче говоря, мы ждем дел, а не слов"
— Дж. Хаммерсли

#Career

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

Все просто - в последнее время появилось много манипулятивной литературы и телеграм-каналов (один из них). Знание методик манипуляции помогает вовремя их распознать и парировать.

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

📝 "Truth is stranger than fiction — to some people, but I am measurably familiar with it."
- Mark Twain, Pudd'nhead Wilson's New Calendar, Ch. XV

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

📝 "Honesty is the best policy — when there is money in it."
- Mark Twain, Speech to Eastman College (1901)

#Career

Второе издание "Building Microservices: Designing Fine-Grained Systems" by Sam Newman
https://www.amazon.com/gp/product/1492034029

#Microservices

The Open Group выпустила стандарт Open Agile Architecture™ https://www.opengroup.org/open-group-publishes-open-agile-architecture Он довольно сильно отличается от вышедшей в прошлом году предварительной версии O-AAF, хотя и базируется на ней, включает основные темы и много чего еще. Стандарт, как и прочие документы Open Group, доступен у них на сайте https://pubs.opengroup.org/architecture/o-aa-standard/

Кому лень читать - одна из немногочисленных картинок O-AA Building Blocks. Вообще, с картинками в стандарте всё плохо, впрочем как всегда. Ну, ничего, со временем нарисуем

В последнее время очень популярными стали обсуждения в стиле Agile vs. Architecture.

Давайте посмотрим, что говорит по этому поводу Agile Manifesto.

Некоторые из принципов Agile Manifesto ( https://agilemanifesto.org/principles.html ):

📝 "Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."

Здесь речь идет о контроле за стоимостью изменения кода. Без этого условия ни о каких изменениях требований на поздней стадии не может быть и речи. А это - архитектурная задача:
- https://martinfowler.com/bliki/DesignStaminaHypothesis.html
- https://martinfowler.com/articles/is-quality-worth-cost.html
- https://martinfowler.com/articles/designDead.html
- Глава "7 Modifiability" книги "Software Architecture in Practice" 3d edition by Len Bass, Paul Clements, Rick Kazman

📝 "Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."

Поддержание постоянства velocity - тоже задача архитектуры.

📝 "Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
Continuous attention to technical excellence and good design enhances agility."

Прямым текстом: "good design enhances agility".

На этом принципе особенно акцентируется Craig Larman в статье "Architecture & Design"
- https://less.works/less/technical-excellence/architecture-design.html
Перевод на Русский:
- https://less.works/ru/less/technical-excellence/architecture-design

📝 "Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
The best architectures, requirements, and designs emerge from self-organizing teams."

Прямым текстом: "architectures emerge". Что еще можно здесь добавить?

📝 "Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

Ключевое слово - effective. Я не понимаю, как эффективность можно рассматривать в отрыве от архитектуры. Команда сама решает что ей использовать для эффективности. А если послушать Kent Beck в XP2, то архитектор - участник команды.

Теперь ключевые моменты самого Манифеста ( https://agilemanifesto.org/ ):

📝 "Работающий продукт важнее исчерпывающей документации.
Working software over comprehensive documentation"

Логично. Разве архитектура добивается не того же? Quality Attributes предъявляются к программе или к её документации?

При этом стоит пометка:

📝 "То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
That is, while there is value in the items on the right, we value the items on the left more."

Вот оно как. Оказывается, Agile не отрицает документирование!

📝 "Готовность к изменениям важнее следования первоначальному плану.
Responding to change over following a plan."

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

Это я просмотрел только Манифест, и даже не открывал Len Bass, Grady Booch, Craig Larman, Neal Ford и других знатоков архитектуры.

Формулировка "Agile vs. Architecture" является в корне неверной, если, разумеется, понимать отличие между BDUF, Architecture и Documentation. Потому что Agility (гибкость) в принципе не может быть достигнута без качественной архитектуры. И единственное логическое объяснение, которое я нахожу подобным заблуждениям - это малоразмерность и молодость проектов адептов такого мнения.

#Agile #SoftwareDesign #SoftwareArchitecture

Kent Beck о роли Архитектора в XP (Agile) команде:

📝 "Architects

Architects on an XP team look for and execute large-scale refactorings, write system-level tests that stress the architecture, and implement stories. Architects apply their expertise a little bit at a time throughout the project. They direct the architecture of the project throughout its evolution. The architecture for a little system should not be the same as for a big system. While the system is little the architect makes sure the system has just the right little architecture. As the system grows, the architect makes sure the architecture keeps pace.

Making big architectural changes in small, safe steps is one of the challenges for an XP team. The principle of the alignment of authority and responsibility suggests that it is a bad idea to give one person the power to make decisions that others have to follow without having to personally live with the consequences. Architects sign up for programming tasks just like any programmer. However, they are also on the lookout for big changes that have big payoffs.

Tests can communicate architectural intent. I talked with the architect of a major credit card processor who said that in such a high-capacity environment you don't want any architecture that might get in the way. To achieve this his team had a sophisticated stress testing environment. When they wanted to improve the architecture they would first improve the stress tests until the system broke. Then they would improve the architecture just enough to run the tests.

I suggested this strategy to an architect at another company. He complained of spending all of his time writing specifications and then explaining them to developers. He was frustrated that he didn't have time to code any more. I suggested he write a testing infrastructure and then use tests instead of specifications and explanations. If he saw a hole in a design he should write a failing test to point it out. I wasn't able to convince him to try the idea, but I still think it's valuable.

Another task for architects on an XP team is partitioning systems. Partitioning isn't an up-front, once-and-for-all task, though. Rather than divide and conquer, an XP team conquers and divides. First a small team writes a small system. Then they find the natural fracture lines and divide the system into relatively independent parts for expansion. The architects help choose the most appropriate fracture lines and then follow the system as a whole, keeping the big picture in mind as the groups focus on their smaller section."
- "Extreme Programming Explained" 2nd edition by Kent Beck

#Agile #SoftwareDesign #SoftwareArchitecture

Новый доклад от Vladik Khononov ( @vladik_kh ):
"Case Study: Large-Scale Marketing System - DDD Europe 2020"
https://youtu.be/0qsAxb3L8GM

#DDD

Хороший сборник советов от Craig Larman, автора терминов GRASP и LESS. Ориентирован на всех - управленцев, архитекторов, разработчиков.
- In English https://less.works/less/technical-excellence/architecture-design.html
- На Русском https://less.works/ru/less/technical-excellence/architecture-design

#Agile #SoftwareDesign #SoftwareArchitecture

Опубликована четвертая (заключительная) статья мини-серии статьей про Agile and Architecture by Gregor Hohpe (автор EIP)
"Lack of Discipline is Agile Failure Mode #1. Slow Chaos isn’t Order."
https://architectelevator.com/transformation/agile-discipline/

#Agile #SoftwareArchitecture