Кстати, на тему размера 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

📝 "Отдельные лица приобретают дешевый авторитет, оснастив свою речь жаргоном: они могут проповедовать и выставлять напоказ поверхностные суждения. Но от математиков-профессионалов требуются не их разглагольствования и даже не степень их осведомленности в тех или иных математических вопросах, а готовность применять свои знания и способность реально решать возникающие на практике математические задачи. Короче говоря, мы ждем дел, а не слов"
— Дж. Хаммерсли

#Career

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

Все просто - в последнее время появилось много манипулятивной литературы и телеграм-каналов (один из них). Знание методик манипуляции помогает вовремя их распознать и парировать.

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

📝 "Truth is stranger than fiction — to some people, but I am measurably familiar with it."
- Mark Twain, Pudd'nhead Wilson's New Calendar, Ch. XV

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

📝 "Honesty is the best policy — when there is money in it."
- Mark Twain, Speech to Eastman College (1901)

#Career

Второе издание "Building Microservices: Designing Fine-Grained Systems" by Sam Newman
https://www.amazon.com/gp/product/1492034029

#Microservices

The Open Group выпустила стандарт Open Agile Architecture™ https://www.opengroup.org/open-group-publishes-open-agile-architecture Он довольно сильно отличается от вышедшей в прошлом году предварительной версии O-AAF, хотя и базируется на ней, включает основные темы и много чего еще. Стандарт, как и прочие документы Open Group, доступен у них на сайте https://pubs.opengroup.org/architecture/o-aa-standard/

Кому лень читать - одна из немногочисленных картинок O-AA Building Blocks. Вообще, с картинками в стандарте всё плохо, впрочем как всегда. Ну, ничего, со временем нарисуем