В чате канала прозвучал очень хороший вопрос, на который лучше ответить здесь: "А как же вариант переусложнения как раз по причине "мы прочитали, надо так ..." ?"

В своей практике я не могу вспомнить такого случая. В нечитающих командах проблем всегда на порядок больше. Любое решение имеет свой контекст применения. Универсального решения не существует. Если решение не соответствует поставленной задачи, значит, читали не то или не о том. Т.е. не обладают теорией. Часто можно наблюдать ошибочное применение решений на основе разнообразных статей не самого высокого качества, в которых утрачен контекст применения (наглядный пример - бесчисленные на сегодня статьи о ТДД, в которых отсутствует даже элементарное понимание этой методики). Тут вопрос заключается просто в качестве источников информации - нужно просто быть избирательным и предпочитать работать с первоисточниками. По этому поводу красиво сказал Bertrand Meyer:

📝 "The zealots of an idea are often more extreme than its creators - the phase “more royalist than the King” captures that phenomenon - and you will find that foundational agile texts, such as those by Beck, Larman or Cockburn, occupy a higher plane of discourse; in particular they avoid below-the-belt hits at other approaches."
- “Agile!: The Good, the Hype and the Ugly” by Bertrand Meyer

К сожалению, многие считают, что, например, для понимания паттернов, достаточно почитать статью в Википедии, или послушать "пересказ книги". Эффект от такого экспресс-обучения будет, скорее, негативным, нежели позитивным.

Вторым, немаловажным моментом, является "Несовпадение фаз спиралей обучения"
- https://dckms.github.io/system-architecture/emacsway/soft-skills/learning-spiral-phase-mismatch.html

#Career

Но нередко на практике можно встретить и третий момент - неприняние отдельными разработчиками подходящего под проблему решения в силу психологических причин - "Эффекта Даннинга-Крюгера", "Психологической Защиты" и "Confirmation Bias":
- https://ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%94%D0%B0%D0%BD%D0%BD%D0%B8%D0%BD%D0%B3%D0%B0_%E2%80%94_%D0%9A%D1%80%D1%8E%D0%B3%D0%B5%D1%80%D0%B0
- 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
- https://ru.m.wikipedia.org/wiki/%D0%97%D0%B0%D1%89%D0%B8%D1%82%D0%BD%D1%8B%D0%B9_%D0%BC%D0%B5%D1%85%D0%B0%D0%BD%D0%B8%D0%B7%D0%BC
- https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B0_%D0%B2%D1%8B%D0%B6%D0%B8%D0%B2%D1%88%D0%B5%D0%B3%D0%BE

Лечится это, опять же, ростом персональной компетентности участников команды. На эту тему уже был пост:
https://news.1rj.ru/str/emacsway_log/47

Как бы то ни было, а старина Леонардо да Винчи был прав:

📝 "Всякий, кто полагается на практику, не зная теории, подобен кормчему, вступающему на судно без руля и компаса, – он не знает, куда плывет. Практика всегда должна опираться на твердые теоретические основания."
- Леонардо да Винчи

Другой вопрос о том, что "чтения недостаточно". Да, недостаточно, на эту тему уже упоминалась превосходная статья Сергея Теплякова "О “вреде” книг: напутствие любому программисту":
https://sergeyteplyakov.blogspot.com/2017/02/reading-books-considered-harmful.html?m=1

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

#Career #SoftwareDesign #SoftwareArchitecture

Превосходная подборка статей с фундаментальной информацией в доступной форме о внутреннем устройстве PostgreSQL, от разработчиков PostgresPro:

- https://m.habr.com/ru/company/postgrespro/blog/442804/
- https://m.habr.com/ru/company/postgrespro/blog/458186/
- https://m.habr.com/ru/company/postgrespro/blog/459250/
- https://m.habr.com/ru/company/postgrespro/blog/460423/
- https://m.habr.com/ru/company/postgrespro/blog/461523/

Видеозаписи курсов по PostgreSQL: https://postgrespro.ru/education/where

#Database #PostgreSQL

Jimmy Bogard: "ugh another "GraphQL vs REST" post" (см. весь тред):
- https://twitter.com/jbogard/status/1306960118270046210?s=19

Ранее он уже затрагивал эту тему:
- https://twitter.com/jbogard/status/1165968651863937024?s=19
- https://twitter.com/jbogard/status/1021460946315825152?s=19

#DDD #Microservices #SowtwareDesign #SoftwareArchitecture #REST #GraphQL

Vaughn Vernon ответил на зарождающуюся тенденцию mAcroservices:
"Microservices and [Micro]services"
https://kalele.io/microservices-and-microservices/

[UPDATED]: Короткий пересказ:
https://twitter.com/VaughnVernon/status/1307531621235523586?s=19

#DDD #Microservices

Кстати, на тему размера microservice недавно писал Alberto Brandolini:
"About Bounded Contexts and Microservices"
https://blog.avanscoperta.it/2020/06/11/about-bounded-contexts-and-microservices/

Там же он рассматривает и вопрос связи Bounded Context с Microservice. Но лучше всех этот вопрос раскрыл, по моему мнению, Vladik Khononov ( @vladik_kh ):
- "Bounded Contexts are NOT Microservices"
https://vladikk.com/2018/01/21/bounded-contexts-vs-microservices/
- "Tackling Complexity in Microservices"
https://vladikk.com/2018/02/28/microservices/
- "DDDDD: Bounded Contexts, Microservices, and Everything In Between"
https://youtu.be/Z0RgR9xIQE4

#DDD #Microservices

Очередной холивар титанов, на этот раз на тему паттернов проектирования:
https://twitter.com/copyconstruct/status/1306661608454721537?s=19

#OOP #SoftwareDesign #SoftwareArchitecture

В продолжение темы о Story Point. Возможно, это удивит многих. Вот что говорит человек, который считается одним из его создателей:

Ron Jeffries:
> i was there when story points were invented and they are about time, no more and no less.
https://twitter.com/RonJeffries/status/1295135210976301057?s=20

Ron Jeffries:
> Story points as we originally defined them are in fact numbers. They are estimated days times a secret constant.
https://twitter.com/RonJeffries/status/1199794376949538817?s=20

Ron Jeffries:
> You seemed to be comparing time-in-queue plus time-in-development to story point estimate. Points as originally contemplated only consider time in development. That time starts when the team pulls the story.
https://twitter.com/RonJeffries/status/1192092142639943680?s=20

Ron Jeffries:
> Story points are time to implement once you start implementing, times an arbitrary constant. That's all they are. Much of what you wrote above sounded like cycle time ... and points aren't that.
https://twitter.com/RonJeffries/status/1191867124035158016?s=20

Ron Jeffries:
> OK, experts who think story points aren't about cost, and that cost isn't essentially time, educate me. What are they, what are they good for, why do we estimate them?
In answering, show no concern for the likelihood that I invented them.
If I did, I'm sorry now.
https://twitter.com/RonJeffries/status/1128296444845330433?s=20

Ron Jeffries:
> No. However, the whole point of story points, like all other forms of story cost estimation, is to figure out how long things will take (or, the equivalent, how much work to take on in some interval).
If they can't be added, they are entirely without value.
https://twitter.com/RonJeffries/status/1128290085714186242?s=20

Ron Jeffries:
> i was there when story points were invented, and while i don't like them and regret past support for them, i can tell you that they were built to be proportional to time, and additive.
https://twitter.com/RonJeffries/status/1128070252275884037?s=20

Ron Jeffries:
> neither hours nor points are discernibly better than counting stories. points were invented to disguise our use of “perfect” days, which was confusing to management. XP never used hours to my recollection.
cf. the no estimates idea.
https://twitter.com/RonJeffries/status/1097601165930442753?s=20

Ron Jeffries:
> we estimated stories initially in "ideal time", later in points, tracked number accomplished to adjust how many to pull each iteration. switched to points because ideal time confused people (why did 2 day story take 5 days).
it worked, i think, because we had low politics.
https://twitter.com/RonJeffries/status/1052858860539658240?s=20

Ron Jeffries:
> points are stories/time*constant. how long you work, not how hard you work.
https://twitter.com/RonJeffries/status/979096172273942528?s=20

Ron Jeffries:
> yes. we had estimated work in “perfect days” and since it takes more than one real day to equal one perfect day, our stakeholders were confused. so we just estimated the same way and called them points. today, i don’t recommend estimating stories at all. small stories [could be used instead]. count them.
https://twitter.com/RonJeffries/status/937207650353319936?s=20

Ron Jeffries:
> original story points were Perfect Engineering Days, one’s estimate of how long it would take if the bastards left us alone.
https://twitter.com/RonJeffries/status/834879258753449989?s=20

Ron Jeffries:
> I am not sure I invented story points but if I did I’m sorry now.
https://twitter.com/RonJeffries/status/943790497981706242?s=20

Ron Jeffries:
> I may have invented story points. If I did, I am sorry now.
https://twitter.com/RonJeffries/status/815924184257851392?s=20

#Agile

Новая статья от Vladimir Khorikov @vkhorikov
"Domain model purity and the current time" https://enterprisecraftsmanship.com/posts/domain-model-purity-current-time/

#DDD #SoftwareDesign

Когда у вас спрашивают для чего нужны DDD и другие методики управления сложностью. У меня эта картинка вызывает ассоциацию с "Законом магического числа семь плюс-минус два".
https://ru.m.wikipedia.org/wiki/%D0%9C%D0%B0%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D1%87%D0%B8%D1%81%D0%BB%D0%BE_%D1%81%D0%B5%D0%BC%D1%8C_%D0%BF%D0%BB%D1%8E%D1%81-%D0%BC%D0%B8%D0%BD%D1%83%D1%81_%D0%B4%D0%B2%D0%B0

На Хабре есть перевод упомянутой статьи:
"Предметно-ориентированная микросервисная архитектура от Uber", автор оригинала: Adam Gluck
https://m.habr.com/ru/company/flant/blog/514830/

#Microservices #DDD

Весьма интересный workshop от Neal Ford:

How do you choose the appropriate granularity for microservices? There are better strategies than leaving this to chance.

"Architecture: The Hard Parts"
2 x 4 hours remote workshop with Zhamak Dehghani, Neal Ford, and Mark Richards
https://training.dddeurope.com/architecture-the-hard-parts-dehghani-ford/

И еще один workshop, заслуживающий внимания, от Vaughn Vernon:

Both of this week's virtual @IDDDWorkshop events sold out, EU and US/Americas. October has two more, EU & Asia/Australia (EU nearly sold out)

- 12-15 October 08:30 - 12:00 CEST

- 13-16 October
- 09:00 AM – 12:30 PM (SGT)
- 11:00 AM - 2:30 PM (AEDT)
https://t.co/MaOHsiiGop

#Microservices #DDD

Новая книга от Nick Tune: "Architecture Modernization with Strategic Domain-Driven Design"
A Guide for Technology Leaders
https://leanpub.com/arch-modernization-ddd

#DDD #SoftwareDesign #SoftwareArchitecture #Microservices

Новая статья от разработчиков Watermill
"Introducing basic CQRS by refactoring a Go project"
https://threedots.tech/post/basic-cqrs-in-go/

#DDD #Microservices

Уже не ново, но все еще актуально. Просто вспомнил сегодня об этом твите:
https://twitter.com/jbogard/status/1291744769266384899?s=19 .
Автор твита в представлениях не нуждается. eShopOnContainers - тоже.

#DDD #Microservices

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

Сколько Martin Kleppmann заработал на своей книге "Designing Data-Intensive Applications" и что ему это стоило, рассказал вчера он сам в своем блоге:
https://martin.kleppmann.com/2020/09/29/is-book-writing-worth-it.html

#DistributedSystems

Именно так выглялит результат обсуждений профессионального сообщеста о том, каким должен быть образ настоящего архитектора 😃:

А это, я так понимаю, - первоисточник и исходный код этой шпаргалки. Коммитил Nick Tune.
EventStorming Glossary & Cheat sheet
https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet

И канонический адрес:
https://ddd-crew.github.io/eventstorming-glossary-cheat-sheet/

#DDD #EventStorming

Свежий пост от Nick Tune на актуальную тему "Self-documenting Architecture"
https://medium.com/nick-tune-tech-strategy-blog/self-documenting-architecture-80c8c2429cb8

#DDD #SoftwareArchitecture