Не столько интересны конкретные реализации, сколько тенденция формирования тренда в Golang:

#Golang #CleanArchitecture

Формирование каталога "Patterns of Distributed Systems" https://martinfowler.com/articles/patterns-of-distributed-systems/ уже завершено.

#DistributedSystems

Просто золотой мануал по согласованностям:
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