#DDD #DistributedSystems

Rambler делится опытом перехода от Python к Rust:
- https://m.habr.com/ru/company/rambler_group/blog/533268/
- https://m.habr.com/ru/company/rambler_group/blog/535234/

#FunctionalProgramming

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

"Always-Valid Domain Model" by Vladimir Khorikov
https://enterprisecraftsmanship.com/posts/always-valid-domain-model/

#DDD #SoftwareDesign

"Decentralised content moderation" by Martin Kleppmann
https://martin.kleppmann.com/2021/01/13/decentralised-content-moderation.html

#SoftwareArchitecture #DistributedSystems

"Pairing Guidelines" by Rober Martin
http://blog.cleancoder.com/uncle-bob/2021/01/17/Pairing.html

#SoftwareDevelopment

"How to always be right (100% fair-trade vegan and snake oil-free). Or at least be better prepared for being wrong." by Gregor Hohpe
https://architectelevator.com/strategy/always-be-right/

#SoftwareArchitecture #Career

Статья наглядно показывает, как эффективность команды может быть улучшена более чем на порядок.
"Maximizing Developer Effectiveness" by Tim Cochran
https://martinfowler.com/articles/developer-effectiveness.html

#SoftwareArchitecture #SoftwareDevelopment

Добавлены пара новых статей в Patterns of distributed systems:

"Consistent Core"
https://martinfowler.com/articles/patterns-of-distributed-systems/consistent-core.html

"Lease"
https://martinfowler.com/articles/patterns-of-distributed-systems/time-bound-lease.html

#SoftwareArchitecture #DistributedSystems

"ArchiMate Cookbook" by Eero Hosiaisluoma
https://www.hosiaisluoma.fi/blog/archimate/

#SoftwareArchitecture

#Database #PostgreSQL

В продолжение статьи "Роль архитектуры в масштабировании команд, 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