В продолжение статьи "Роль архитектуры в масштабировании команд, DDD и микросервисах"
- https://dckms.github.io/system-architecture/emacsway/it/team-topologies/harlan-mills%27-proposal.html

Превосходство Monolith First заключается в том, что он удешевляет изменение концептуальных контуров, что, зачастую, неизбежно в процессе Crunching Knowledge. На начальной стадии развития проекта обычно не возникает тех предпосылок, в которых может проявить свои превосходства микросервисная архитектура, что делает Monolith First экономически целесообразным.

Но означает ли это то, что Microservices First всегда экономически нецелесообразен? Нет, не означает. И, чтобы понять, когда наступает его экономическая целесообразность, нам нужно обратиться к известной работе Frederick P. Brooks, Jr. "The Mythical Man-Month Essays on Software Engineering Anniversary Edition".

С одной стороны, Monolith First получается дешевле, так как удешевляет эволюционирование Доменной Модели и изменение концептуальных контуров.

С другой стороны, Microservices First (не прямо, а косвенно, посредством концепции Bounded Contexts) позволяет достигнуть такого уровня автономности команд, который позволяет задействовать сразу большое количество разработчиков. Получается дорого, но быстро.

Каждое решение - это баланс выгод и затрат. Быстрота тоже выражается деньгами. Если оверхед от микросервисов перекрывается выгодой от более раннего выхода на рынок - TTM (time-to-market), то Microservices First может оказаться экономически целесообразней.

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

На другой чаше весов у нас ущерб упущенной выгоды от более позднего выхода продукта на рынок.

Решение является балансом. Для этого рассматривается график экономии от Monolith First и график ущерба упущенной выгоды от роста TTM.

Там где эти графики пересекаются - возникает точка баланса. Вопрос лежит исключительно в бизнес-плоскости.

Если ущерб упущенной выгоды перевешивает, то применяется Microservices First, иначе - Monolith First.

Зачастую, Monolith First оказывается выгоднее. Но экономическая целесообразность Monolith First может оказаться ниже ущерба упущенной выгоды от роста TTM, и тогда баланс решения качнется в сторону Microservices First. Этот баланс зависит от условий каждого конкретного проекта в отдельности. Серебрянной пули нет.


#DDD #Microservices #SoftwareArchitecture

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

Недавно мне попалась статья, в которой именно о таком генерале рассказывает прославленный ас Александр Покрышкин:

📝 ""Однажды возле командного пункта я увидел незнакомого летчика, высокого, стройного, в шлемофоне и кожаной куртке. По его внешнему виду и осанке я предположил, что это какой-то большой начальник, и постарался, не попадаясь ему на глаза, пройти в землянку. Но когда я вышел оттуда, он сам меня окликнул: "Покрышкин?" — "Так точно!" — отозвался я, отдавая честь. И только тут заметил на его галифе генеральские лампасы. По каким-то едва уловимым приметам я заключил, что генерал только что возвратился с боевого задания и полет этот прошел не совсем удачно. "Савицкий", — назвал он свою фамилию. Так вот он каков, командир прилетевшего к нам соединения истребителей! Только прибыл на фронт и уже сам побывал в бою".

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

"Лично летает на боевые задания""

- "Позывной — "Дракон". Как воевал и жил маршал, мечтавший никогда не расставаться с небом"
https://tass.ru/opinions/10342867

P.S.: Перед новым годом, воспользовавшись предпраздничным настроением на работе, массовыми отпусками и спокойной обстановкой, позволил себе попрограммировать пару недель. Теперь мне не стыдно смотреть в глаза Grady Booch, Craig Larman, Gregor Hohpe, Kent Beck, Martin Fowler, Robert C. Martin, и другим сторонникам "пишущих код архитекторов". Получил море удовольствия, и надеюсь изыскать время, чтобы закончить начатую библиотеку в обозримом будущем.

#Career #SoftwareArchitecture

"Architecture Ownership Patterns for Team Topologies. Part 3: Multi-Team Patterns" by Nick Tune
https://medium.com/nick-tune-tech-strategy-blog/architecture-ownership-patterns-for-team-topologies-part-3-multi-team-patterns-eecc146ddb28

#DDD #Microservices #SoftwareArchitecture

Последняя статья Kent Beck определенно представляет интерес для всех управленцев. Его рассуждения на тему "A recruiter I met recently said they had eliminated incentive-based bonuses for executives. Performance, much to his surprise, improved."

"Does Pay-For-Performance Perform?" by Kent Beck
https://medium.com/@kentbeck_7670/does-pay-for-performance-perform-64f1d3363e0

#Career #Management

"State Watch. Notify clients when specific values change on the server"
https://martinfowler.com/articles/patterns-of-distributed-systems/state-watch.html

#SoftwareArchitecture #DistributedSystems

#DDD #Microservices #SoftwareArchitecture

#Database #PostgreSQL

Новая статья от разработчиков Watermill: "Microservices test architecture. Can you sleep well without end-to-end tests?"
https://threedots.tech/post/microservices-test-architecture/

#DDD #Microservices

Дополнение статьи:
https://martinfowler.com/articles/developer-effectiveness.html#OrganizationalEffectiveness

#SoftwareArchitecture #SoftwareDevelopment

Новая статья в цикле:
"Idempotent Receiver. Identify requests from clients uniquely so they can ignore duplicate requests when client retries"
https://martinfowler.com/articles/patterns-of-distributed-systems/idempotent-receiver.html

#SoftwareArchitecture #DistributedSystems

Пара новых статей:
"Pull Request"
https://martinfowler.com/bliki/PullRequest.html

"Refinement Code Review"
https://martinfowler.com/bliki/RefinementCodeReview.html

#CVS #Git