Несколько неплохих ссылок по 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

Просто превосходный краткий материал по проектированию микросервисов:
"Building microservices on Azure"
- https://docs.microsoft.com/en-us/azure/architecture/microservices/

Особенно это:
- "Using domain analysis to model microservices" https://docs.microsoft.com/en-us/azure/architecture/microservices/model/domain-analysis
и это:
- "Identifying microservice boundaries" https://docs.microsoft.com/en-us/azure/architecture/microservices/model/microservice-boundaries

#DDD #Microservices

Выглядит неплохо. Заслуживает внимания.
Architecture Playbook
https://nocomplexity.com/documents/arplaybook/index.html

#SoftwareArchitecture #SoftwareDesign #Microservices

"Architecture Ownership Patterns For Team Topologies. Part 1: A Business Architecture Model" by Nick Tune
- https://medium.com/nick-tune-tech-strategy-blog/team-responsibility-ownership-patterns-part-1-a-business-architecture-model-63597c4e60e1

"Architecture Ownership Patterns for Team Topologies. Part 2: Single Team Patterns" by Nick Tune
- https://medium.com/nick-tune-tech-strategy-blog/architecture-ownership-patterns-for-team-topologies-part-2-single-team-patterns-943d31854285

Цикл статей о том, как выравнивать команды и компоненты системы. Полезна всем, кто распределяет зоны ответственностей команд.

#DDD #Microservices #SoftwareArchitecture

Прошу меня извинить за столь длительную паузу в рассмотрении темы Monolith First vs. Microservices First. После праздников накопилось много дел.

По этой теме я хотел бы добавить еще одно высказывание от разработчиков популярного микросервисного фреймворка go-kit:

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

Why microservices? Almost all of contemporary software engineering is focused on the singular goal of improving time-to-market. Microservices are an evolution of the service-oriented architecture pattern that elegantly eliminate organizational friction, giving your engineers and teams the autonomy they need to continuously ship, iterate, and improve."
- Go kit. A toolkit for microservices.
https://gokit.io/

#DDD #Microservices #SoftwareArchitecture

Таким образом, с одной стороны, 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. Этот баланс зависит от условий каждого конкретного проекта в отдельности. Серебрянной пули нет.

Причем здесь микросервисы? На самом деле, если у вас армейская дисциплина среди разработчиков, то нет необходимости укреплять сетевыми границами пределы автономии команд. Собственно, в таком случае не было бы потребности и в статической типизации языков программирования.

📝 "In theory, you don’t need microservices for this if you simply have the discipline to follow clear rules and establish clear boundaries within your monolithic application; in practice, I’ve found this to be the case only very rarely.)"
- "Don’t start with a monolith" by Stefan Tilkov
https://martinfowler.com/articles/dont-start-monolith.html

Сетевые границы решают проблему, известную как creeping coupling или abstraction leak. А это позволяет снизить квалификационные требования к разработчикам, тем более, что Microservices First обычно имеет экономическую целесообразность только при задействовании большого количества разработчиков.

📝 "Обмен данными между самими сервисами ведется через сетевые вызовы, чтобы упрочить обособленность сервисов и избежать рисков, сопряженных с тесными связями.

All communication between the services themselves are via network calls, to enforce separation between the services and avoid the perils of tight coupling."
- "Building Microservices. Designing Fine-Grained Systems" by Sam Newman

#DDD #Microservices #SoftwareArchitecture

Превосходная статья по Causal Consistency (Causal Dependencies) доступным языком:
"HighLoad++, Михаил Тюленев (MongoDB): Causal consistency: от теории к практике"
https://habr.com/ru/company/ua-hosting/blog/487638/

[UPDATE]: Есть ещё видео-версия:
- https://youtu.be/UnAprFMX1d4

#DDD #Microservices #DistributedSystems #EIP

"Forget monoliths vs. microservices. Cognitive load is what matters."
от авторов книги "Team Topologies"
- https://techbeacon.com/app-dev-testing/forget-monoliths-vs-microservices-cognitive-load-what-matters

Thanks to @romanvt

#Microservices #TeamTopologies #Management #SoftwareArchitecure