Ответ Jimmy Bogard по поводу того, может ли CQRS-Команда возвращать результат:

📝 "It might seem rather strange that commands always have a result, but it’s much, much easier to deal with side effects of commands through return parameters than through some other means (global registry, static field, re-querying some object, collecting parameter, etc.). For commands that create an item, I usually want to redirect to a screen showing that item, very easily accomplished when I can get the created item and as for its ID.

This is a bit controversial, but don’t frankly care, as it’s the simplest thing that could possibly work. If I want to have a command that returns Void, I could steal a page from F# and have a Command base class that returns a Unit type:"
- "Put your controllers on a diet: POSTs and commands" by Jimmy Bogard
https://lostechies.com/jimmybogard/2013/12/19/put-your-controllers-on-a-diet-posts-and-commands/

Обратите внимание, в последнем предложении он говорит о том, как вернуть и результат, и ошибку одновременно. Именно об этом шла речь здесь: https://news.1rj.ru/str/emacsway_log/279

Причины такого решения он раскрывает в другой своей статье:

📝 "Myth #2 – CQRS requires an eventual consistent read store

No, it does not. You can make your read store immediately consistent. That is, your read store can be updated when your command side succeeds (in the same transaction).

For many legacy/existing apps, transitioning to eventually consistent read stores will either force you to go through bogus hoops of mimicking synchronous calls. Users will bang down on your door with pitchforks and torches if you try and transition to an asynchronous model if you don’t change their business process first.

Instead, you can start with immediate consistency and transition where and when it’s needed. Unless a user expects a confirmation page, making every command page have a series of confirmations of “your request was received” is going to annoy the snot out of your users.

Myth #3 – CQRS requires a bus/queues/asynchronous messaging

See above myth. Nothing about CQRS says “thou shalt use NServiceBus”. It’s just not there. You’re merely separating infrastructure between handling commands and queries, but the how is quite varied. Don’t start with a bus until you prove you need eventual consistency.

Consistency models are a business decision because it directly impacts user experience. An eventually consistent model requires a different user experience than an immediate one, and this is not something you can just “slip in” to your users, or try to emulate. If you’re attempting to emulate immediate consistency in an eventually consistent model, you’re doing something wrong.
- “Busting some CQRS myths” by Jimmy Bogard
https://lostechies.com/jimmybogard/2012/08/22/busting-some-cqrs-myths/

Что он также подтверждает своим комментарием к этой статье:

📝 "Scaling and CQRS are orthogonal, it’s highly contextual and certainly doesn’t require async."
- "Busting some CQRS myths" by Jimmy Bogard
https://lostechies.com/jimmybogard/2012/08/22/busting-some-cqrs-myths/#comment-3422377189

Итак, ответ прост - если вы не используете асинхронное исполнение Команды посредством инфраструктуры (Command Bus), то ничто не препятствует вам получить идентификатор вновь созданной записи БД в возвращаемом командой результате, и реализацию можно существенно упростить. Впрочем, возвратить результат можно даже используя Command Bus, но тут вопрос к потреблению ресурсов (все зависит от конкретного случая).

Вопрос не в том, возвращает ли команда реультат (при этом нужно отличать результат от служебной информации, например, от успешности валидации и принятия команды), а в том, можно ли получить информацию о ресурсе без abstract side effect, т.е. смогут ли другие клиенты получить ту же информацию, если она им нужна.

#DDD #Microservices #SoftwareDesign #SoftwareArchitecture #FunctionalProgramming #OOP

"How to handle unique constraint violations" by Vladimir Khorikov
https://enterprisecraftsmanship.com/posts/handling-unique-constraint-violations/

#DDD

Случайно наткнулся на паттерны DDD, выраженные в ArchiMate:
- https://github.com/wilmerkrisp/patterns/tree/master/domain%20driven%20design%20patterns

Поскольку Event Storming - это средство исследования домена, а не документирования, то "C.1.10 Business Process Cooperation Viewpoint" может пригодиться, чтобы задокументировать результат сессии Event Storming:
- https://pubs.opengroup.org/architecture/archimate31-doc/apdxc.html#_Toc10045506

Если вы никогда не использовали ArchiMate, то вряд ли эта ссылка будет для вас сильно информативной. В таком случае лучше скачать Archi® modelling toolkit ( https://www.archimatetool.com/ ) и переключить ViewPoint на Business Process Cooperation Viewpoint. Оно того стоит. Шпаргалка по ArchiMate: https://publications.opengroup.org/n190

Ранее уже говорилось, что и сам Event Storming в чистом виде можно рисовать в ArchiMate:
https://news.1rj.ru/str/emacsway_log/253

#DDD #SoftwareDesign #SoftwareArchitecture #ArchiMate #EventStorming

https://twitter.com/VaughnVernon/status/1336767917778563072?s=19

#DDD #Microservices

Мы в этом канале уже разобрали две большие темы:
- Проблема конкурирующих подписчиков и гонка событий: https://news.1rj.ru/str/emacsway_log/57
- CQRS/CQS и возврат результата командой https://news.1rj.ru/str/emacsway_log/276

Попутно было еще несколько заслуживающих внимания дискуссий в чате канала.

Наверное, все уже отдохнули от "тяжелых" тем, и можно браться за следующую. В последнее время часто вспоминается вопрос Monolith First vs. Microservices First в разных чатах, но при этом упускается один важный, я бы даже сказал - ключевой, момент, на который я хотел бы обратить внимание.

Если кто с этими терминами не знаком, то:
- Monolith First https://martinfowler.com/bliki/MonolithFirst.html
- Microservices First https://martinfowler.com/articles/dont-start-monolith.html

Но прежде чем мы погрузимся в эту тему, я хотел бы, чтобы каждый хорошо осознавал разницу между Microservice и Bounded Context (BC). Это важно, потому что границей автономности команды разработчиков является все-таки BC, а значит, микросервисы способствуют достижению автономности не прямо, а косвенно.

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

Лучшие, на мой взгляд, статьи, поясняющие разницу между Microservice и BC - это:

- “Bounded Contexts are NOT Microservices” by Vladik Khononov
https://vladikk.com/2018/01/21/bounded-contexts-vs-microservices/

- “Tackling Complexity in Microservices” by Vladik Khononov
https://vladikk.com/2018/02/28/microservices/

- “DDDDD: Bounded Contexts, Microservices, and Everything In Between” by Vladik Khononov
https://youtu.be/Z0RgR9xIQE4

- “Using domain analysis to model microservices“
https://docs.microsoft.com/en-us/azure/architecture/microservices/model/domain-analysis

- “Identifying microservice boundaries“
https://docs.microsoft.com/en-us/azure/architecture/microservices/model/microservice-boundaries

- “Reactive Microservices” by Vaughn Vernon
https://kalele.io/reactive-microservices/

- “Microservices and [Micro]services” by Vaughn Vernon
https://kalele.io/microservices-and-microservices/

#DDD #Microservice #SoftwareArchitecture

Новый курс "Validation in DDD" by Vladimir Khorikov:
- https://github.com/vkhorikov/ValidationInDDD

#DDD

С Новым Годом! Ярких побед и высоких достижений в Новом Году! Пусть все задуманное осуществится! Здоровья, благополучия и успехов!)
☃️🥳🍾🎆🎇🎉🎄🎅❄️

"Architecture Ownership Patterns For Team Topologies. Part 1: A Business Architecture Model" by Nick Tune
- https://medium.com/nick-tune-tech-strategy-blog/team-responsibility-ownership-patterns-part-1-a-business-architecture-model-63597c4e60e1

"Architecture Ownership Patterns for Team Topologies. Part 2: Single Team Patterns" by Nick Tune
- https://medium.com/nick-tune-tech-strategy-blog/architecture-ownership-patterns-for-team-topologies-part-2-single-team-patterns-943d31854285

"Architecture Ownership Patterns for Team Topologies. Part 3: Multi-Team Patterns" by Nick Tune
https://medium.com/nick-tune-tech-strategy-blog/architecture-ownership-patterns-for-team-topologies-part-3-multi-team-patterns-eecc146ddb28

Цикл статей о том, как выравнивать команды и компоненты системы. Полезна всем, кто распределяет зоны ответственностей команд.

#DDD #Microservices #SoftwareArchitecture

"Always be experimenting. Doing the exact same thing twice is a wasted opportunity." by Gregor Hohpe
- https://architectelevator.com/strategy/always-be-experimenting/

#SoftwareArchitecture

Now Ruby has built-in actor model and jit.

Python is way behind all modern noscripting languages 😞

I also recommend to watch this talk: https://www.youtube.com/watch?v=Y29SSOS4UOc

#DDD #DistributedSystems

Rambler делится опытом перехода от Python к Rust:
- https://m.habr.com/ru/company/rambler_group/blog/533268/
- https://m.habr.com/ru/company/rambler_group/blog/535234/

#FunctionalProgramming

Друзья, я знаю Павла уже несколько лет. Он тоже работает в российской ИТ-индустрии, и внес свой посильный вклад в развитие его профессиональных сообществ. У кого есть возможность оказать информационную поддержку - просьба зарепостить.

"Always-Valid Domain Model" by Vladimir Khorikov
https://enterprisecraftsmanship.com/posts/always-valid-domain-model/

#DDD #SoftwareDesign