Просто золотой мануал по согласованностям:
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/final-printversion-10-5-14.pdf

#DistributedSystems

Patterns for Managing Source Code Branches by M.Fowler: https://martinfowler.com/articles/branching-patterns.html

#CVS #Git

Несколько полезных ссылок по проектированию API:

- https://docs.microsoft.com/en-us/azure/architecture/microservices/design/api-design
- https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-design
- https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-implementation
- https://github.com/Microsoft/api-guidelines
- https://google.aip.dev/general
- https://microservice-api-patterns.org/
- Web API Design - Crafting Interfaces that Developers Love
https://pages.apigee.com/rs/apigee/images/api-design-ebook-2012-03.pdf

UPDATE2: Другие ссылки по этой теме:
https://emacsway.github.io/ru/self-learning-for-software-engineer/#api-design

#API #DDD #Microservices #DistributedSystems

Прекрасная подборка ссылок по распределенной архитектуре.
Literature references for "Designing Data-Intensive Applications".
This repository accompanies the book Designing Data-Intensive Applications by Martin Kleppmann, published by O'Reilly Media.
https://github.com/ept/ddia-references

#DistributedSystems

Еще одна статья от Gregor Hohpe (автора EIP) на тему Agile.
"Agile Is the Steering Wheel, Not the Gas Pedal"
https://architectelevator.com/transformation/agile-steering/

#Agile #SoftwareArchitecture

В этой своей статье Gregor Hohpe ссылается на интересную статью "Principles for the Agile Architect" by Andrew Johnston
https://www.agilearchitect.org/agile/principles.htm

#Agile #SoftwareArchitecture

На широко обсуждаемую статью Uber
"Introducing Domain-Oriented Microservice Architecture"
https://eng.uber.com/microservice-architecture/
Уже отреагировали:

Grady Booch:
- https://twitter.com/Grady_Booch/status/1288246565988048896?s=19

Martin Fowler:
- https://twitter.com/martinfowler/status/1288107614123909120?s=19

Sam Newman:
- https://twitter.com/samnewman/status/1287469517371826176?s=19
- https://twitter.com/samnewman/status/1287475910430646273?s=19
- https://twitter.com/samnewman/status/1288072774083383297?s=19

И другие.

#Microservices #DDD

Критически важная статья, проливающая свет на один из наиболее частых и болезненных вопросов в DDD:
"Domain model purity vs. domain model completeness" by Vladimir Khorikov
https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/

#DDD

Amazing interactive map of Consistency Models https://jepsen.io/consistency

#DistributedSystems

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

Agile является естественным следствием эволюции итеративной разработки, краткий обзор которой можно посмотреть в превосходной статье Craig Larman https://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf

Лучше всего понимать суть вещей от первоисточника. Пожалуй, наибольшее влияние на Agile оказал Kent Beck. Именно от него нахватался этих идей Robert C. Martin, который в 2001 году организовал встречу группы из числа 17 человек, которые приняли Agile Manifesto.

Kent приводит два графика стоимости изменения кода, по которым может протекать разработка.

Первый график: https://emacsway.github.io/_images/exponential-cost-of-change.png

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

Кое-что произошло в конце 90-х. Много писать не буду, скажу только, что это привело к другому графику, который приводит Kent Beck:
https://emacsway.github.io/_images/asymptotic-cost-of-change.png

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

Scrum включал в себя набор технических практик, заимствованных из XP, нацеленных на снижение стоимости изменения кода. Но это сдерживало продвижение Scrum в массы, так как вносило организационную сложность. Ken Schwaber хотел форсировать распространение Agile, и убедил Jeff Sutherland «оставить инженерные практики за рамками Scrum, чтобы упростить модель и позволить командам брать на себя ответственность за выбор тех или иных практик» (Henrik Kniberg), четко обозначив Scrum как фреймворк, который разработчики, по своему усмотрению, должны дополнять практиками.

Scrum, действительно, стал распространяться вирусно. Но проблема в том, что на технические практики мало кто обращал должное внимание, что приводило к взлету стоимости изменения кода, при котором Agile уже не обладал экономическим превосходством перед BDUF. Это подмочило репутацию Agile на рынке. По этому поводу есть статья на AgileAlliance (сайт основан подписантами манифеста)
https://www.agilealliance.org/how-to-increase-velocity/

#Agile #ExtremeProgramming

Partitioning Improvements in PostgreSQL 13
https://www.highgo.ca/2020/08/08/partitioning-improvements-in-postgresql-13/

#Database #PostgreSQL #HighLoad #Scaling

Шпаргалка по выбору типа хранилища данных:
- https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/data-store-comparison
- https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/data-store-decision-tree

Jepsen's analysis over two dozen databases, coordination services, and queues—and we’ve found replica divergence, data loss, stale reads, read skew, lock conflicts, and much more:
- https://jepsen.io/analyses
- https://aphyr.com/tags/jepsen

Рейтинг хранилищ данных:
https://db-engines.com/en/ranking

#Database

Монументальная статья Bertrand Meyer "OBJECT-ORIENTED VS FUNCTIONAL"
http://se.ethz.ch/~meyer/publications/functional/meyer_functional_oo.pdf
Невозможно не прочитать ее.

#FunctionalProgramming #OOP #SoftwareDesign

Hexagonal Architecture от Alistair Cockburn:
- https://www.youtube.com/watch?v=th4AgBcrEHA
- https://www.youtube.com/watch?v=iALcE8BPs94
- https://www.youtube.com/watch?v=DAe0Bmcyt-4

#SoftwareDesign #HexagonalArchitecture

Статьи на частые вопросы по DDD:

- "What is domain logic?" by Vladimir Khorikov
- "Domain services vs Application services" by Vladimir Khorikov
- "Domain model isolation" by Vladimir Khorikov
- "Email uniqueness as an aggregate invariant" by Vladimir Khorikov
- "How to know if your Domain model is properly isolated?" by Vladimir Khorikov
- "Domain model purity vs. domain model completeness" by Vladimir Khorikov
- "Immutable architecture" by Vladimir Khorikov

- "Bounded Contexts are NOT Microservices" by Vladik Khononov
- "Tackling Complexity in Microservices" by Vladik Khononov
- "DDDDD: Bounded Contexts, Microservices, and Everything In Between" by Vladik Khononov

- "Overselling Event Sourcing" by Alexey Zimarev
- "Event Sourcing and Microservices" by Alexey Zimarev
- "Projections in Event Sourcing" by Alexey Zimarev
- "Event Sourcing and CQRS" by Alexey Zimarev
- "Entities as event streams" by Alexey Zimarev
- "Event Sourcing basics" by Alexey Zimarev
- "What is Event Sourcing?" by Alexey Zimarev
- "Event Sourcing and CQRS" by Alexey Zimarev

- "Effective Aggregate Design" by Vaughn Vernon

- "CQRS, Task Based UIs, Event Sourcing agh!" by Greg Young

- "Clarified CQRS" by Udi Dahan
- "How to create fully encapsulated Domain Models" by Udi Dahan

Актуальная версия списка доступна здесь.

#DDD

Designing a Domain Model to enforce No Duplicate Names [github] Steve Smith.
https://github.com/ardalis/DDD-NoDuplicates
You have some entity in your domain model. This entity has a name property. You need to ensure that this name is unique within your application. How do you solve this problem? This repository shows 11 different ways to do it in a DDD application where the goal is to keep this business logic/rule in the domain model.
#DDD

Новая книга от Gregor Hohpe, автора EIP, "Cloud Strategy: A Decision-based Approach to Successful Cloud Migration":
- https://architectelevator.com/book/cloudstrategy/
- https://www.amazon.com/Cloud-Strategy-Decision-based-Successful-Migration/dp/B08F6TVVTF

#DistributedSystems