Еще одна статья от 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

О том, как выдавить из мозга максимум, и, при этом, продолжать жить, есть очень хорошая книга Барбары Оакли «Думай как математик» http://sergeyteplyakov.blogspot.com/2016/01/book-review-mind-for-numbers.html

Она описывает как работает мозг, и как с ним обращаться, чтобы тратить времени меньше, а достигать - больше.

#Career

Два самых важных совета о самообучении, которые я когда либо слышал.

📝 "A little reading goes a long way toward professional advancement. If you read even one good programming book every two months, roughly 35 pages a week, you’ll soon have a firm grasp on the industry and distinguish yourself from nearly everyone around you."
- "Code Complete" by Steve McConnell

📝 "We become authorities and experts in the practical and scientific spheres by so many separate acts and hours of work. If a person keeps faithfully busy each hour of the working day, he can count on waking up some morning to find himself one of the competent ones of his generation."
- William James

#Career

Actor Model на Golang:
- https://github.com/AsynkronIT/protoactor-go

Примеры:
- https://github.com/AsynkronIT/protoactor-go/tree/dev/_examples

Дока:
- https://proto.actor/docs/golang/

Учебный материал на Русском:
- https://github.com/AsynkronIT/protoactor-bootcamp/tree/master/C%23/RUS

Thanks to Alexey Zimarev!

#ActorModel #DDD

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

P.S.: Невероятно актуально для современной ИТ-индустрии, хотя и было сказано более 100 лет тому назад...

На эту же тему:

📝 "Professionals avoid getting so vested in an idea that they can’t abandon it and turn around. They keep an open mind about other ideas so that when they hit a dead end they still have other options."
- "Clean Coder" by Robert C. Martin

📝 "A good architecture comes from understanding it more as a journey than as a destination, more as an ongoing process of enquiry than as a frozen artifact."
- "Clean Architecture" by Robert C. Martin

📝 "Travel light - You can't expect to carry a lot of baggage and move fast.

The artifacts we maintain should be:

- Few
- Simple
- Valuable

The XP team becomes intellectual nomads, always prepared to quickly pack up the tents and follow the herd.

The herd in this case might be a design that wants to go a different direction than anticipated, or a customer that wants to go a different direction than anticipated, or a team member who leaves, or a technology that suddenly gets hot, or a business climate that shifts.

Like the nomads, the XP team gets used to traveling light.

They don't carry much in the way of baggage except what they must have to keep producing value for the customer—tests and code.

<...>

Travel light - suggests that the manager doesn't impose a lot of overhead - long all-hands meetings, lengthy status reports.

Whatever the manager requires of the programmers shouldn't take much time to fulfill.

<...>

Travel light - The design strategy should produce no "extra" design.

There should be enough to suit our current purposes (the need to do quality work), but no more.

If we embrace change, we will be willing to start simple and continually refine."
- "Extreme Programming Explained" by Kent Beck

На практике, достигнуть этого состояния не просто, и оно требует определенной дисциплины. В психологии это известно как Confirmation bias. Это и есть тот самый "груз", который ограничивает легкость "свободы предвижения".
- https://ru.wikipedia.org/wiki/%D0%A1%D0%BA%D0%BB%D0%BE%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%BA_%D0%BF%D0%BE%D0%B4%D1%82%D0%B2%D0%B5%D1%80%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D1%8E_%D1%81%D0%B2%D0%BE%D0%B5%D0%B9_%D1%82%D0%BE%D1%87%D0%BA%D0%B8_%D0%B7%D1%80%D0%B5%D0%BD%D0%B8%D1%8F

#Career

Хорошая статья о том, когда оправдано применять CRUD: https://blogs.msdn.microsoft.com/maarten_mullender/2004/07/23/crud-only-when-you-can-afford-it-revisited/

#DDD

На тему оценивания задач. Многие слышали про Story Point, но не многие знают его смысл и назначение, из-за чего он часто применяется неправильно.

История создания и смысл Story Point приводятся на сайте Agile Alliance - организации, созданной основателями Agile Manifesto. Сегодня это наиболее авторитетный интернет-сайт в области Agile: https://www.agilealliance.org/glossary/points-estimates-in/

А в следующей статье, один из ведущих авторитетов в области оценивания, Mike Cohn, рассказывает о связи между Story Points и единицами времени (часами): http://www.mountaingoatsoftware.com/blog/how-do-story-points-relate-to-hours

Пожалуй, лучшими книгами в области оценивания, являются:

- "Software Estimation: Demystifying the Black Art (Developer Best Practices)" by Steve McConnell

- "Agile Estimating and Planning" by Mike Cohn

В кратком, но достаточном для рядового разработчика, варианте, информацию об оценивании можно обрести в:

- "Clean Coder" by Robert C. Martin

#Agile

Eric Evans про Functional Programming в DDD (разверните п.5): https://www.infoq.com/interviews/Technology-Influences-DDD/

А здесь (на 51:25) Eric Evans говорит о том, что в своей книге DDD он не рассматривал глубоко функциональную парадигму потому, что в 2003 она не имела такого широкого применения, как сегодня. А сегодня, в контексте Event Sourcing, она имеет уже совсем другое значение: https://youtu.be/dnUFEg68ESM

Кстати, говоря про Event Sourcing, вот здесь Greg Young рассматривает переход от OOP к FP в ES: https://vimeo.com/131636650

#FunctionalProgramming #DDD

Вот эта картинка мне очень нравится