Говоря о side effect ( https://news.1rj.ru/str/emacsway_log/278 ), B.Meyer накладывает ограничение на "abstract side effect", и поясняет на примере. Сразу скажу, без прочтения главы 11 вряд ли можно понять о чем здесь идет речь. Но обойти вниманием этот пример тоже нельзя.

📝 "Unfortunately, this would be unacceptably restrictive, explaining why the Command-Query Separation principle only prohibits abstract side effects, a notion that will now be defined. The problem is that some concrete side effects are not only harmless but necessary. They are of two kinds.

<...>

Side effects of the second acceptable category may change the state of the object, but only affecting properties that are not visible to clients. To understand the concepts in depth, it will be useful to make sure that you are familiar with the discussion of “abstraction function” and “implementation invariants” in the presentation of Design by Contract. (In particular, take a look at the accompanying figures to refresh your memory.)

We saw then that an object of our software (a concrete object) is the representation of an abstract object, and that two concrete objects may represent the same abstract object.

For example two different stack representations, each made of an array and a top marker count, represent the same stack if they have the same value for count and the same array elements up to index count. They may differ in other properties, such as the array sizes and the values stored at indices above count. In mathematical terms, every concrete object belongs to the domain of the abstraction function a, and we can have c1 ≠ c2 even with a(c1) = a(c2).

What this means for us is that a function that modifies a concrete object is harmless if the result of this modification still represents the same abstract object — yields the same a value. For example assume in a function on stacks contains the operation

representation.put (some_value, count + 1)

(with the guarantee that the array’s capacity is at least count + 1). This side effect changes a value above the stack-significant section of the array; it can do no ill.

More generally, a concrete side effect which changes the concrete state of an object c is an abstract side effect if it also changes its abstract state, that is to say the value of a (c) (a more directly usable definition of abstract side effects will appear shortly). If a side effect is only concrete — does not affect the abstract state — it is harmless.

In the object-as-machine metaphor, functions producing concrete-only side effects correspond to query buttons that may produce an internal state change having absolutely no effect on the answers given by any query button. For example the machine might save energy by automatically switching off some internal circuits if nobody presses a button for some time, and turning them on again whenever someone presses any button, queries included. Such an internal state change is unnoticeable from the outside and hence legitimate." (там же)

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

И последнее сообщение на тему CQS. Далее мы будем рассматривать уже CQRS. Как видим, тема CQS намного более обширна и тонка, чем может показаться на первый взгляд. И за один день её точно не освоить.

Для погружения в CQRS нужно обратить внимание на еще два существенных момента.

Момент первый - routine может возвращать информацию наружу не только в виде возвращаемого значения, но и путем изменения объекта, переданного аргументом по ссылке.

📝 "Function clone creates a new object as a carbon copy of an existing one. Sometimes the target object already exists; all we want to do is to overwrite its fields. Procedure copy achieves this. It is called through the instruction x.copy (y)"
- "Object-Oriented Software Construction" 2nd edition by Bertrand Meyer, chapter "8.6 OPERATIONS ON REFERENCES :: Object copying"

Именно на этом основан Notification Pattern, который широко применяется в языках, не поддерживающих механизм исключений (Golang, например):
https://martinfowler.com/eaaDev/Notification.html

Как можно организовать ссылочную связь через сетевое взаимодействие? Через идентификатор адресации в виде callback url.

И второй момент - это известный кейс с примером, широко известным как метод .pop(), который одновременно и удаляет, и возвращает элемент списка.

B.Meyer решает эту проблему с помощью концепции буффера:

📝 "buffer — the concurrent equivalent of a first-in, first out queue."
- "Object-Oriented Software Construction" 2nd edition by Bertrand Meyer, chapter "23.1 SIDE EFFECTS IN FUNCTIONS :: Objections"

И приводит пример:

next_element := buffer.item
buffer.remove

📝 "With the notation of this chapter, it is easy to obtain exclusive access without sacrificing the Command-Query Separation principle: simply enclose the two instructions above, with buffer replaced by b, in a procedure of formal argument b, and call that procedure with the attribute buffer as argument."
- "Object-Oriented Software Construction" 2nd edition by Bertrand Meyer, chapter "30.12 DISCUSSION :: Support for command-query separation"

Вы уже, наверное, догадались, что я подвожу к паттерну "Asynchronous Request-Reply pattern" ( https://docs.microsoft.com/en-us/azure/architecture/patterns/async-request-reply ), использующему "202 Response Status Code" ( https://tools.ietf.org/html/rfc7231#section-6.3.3 ).

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

Было много всего написано, поэтому подведем итог:

1. CQS - это больше о Query, нежели о Command, где основная цель - достижение referential transparency:
- https://news.1rj.ru/str/emacsway_log/279

2. Query не должен иметь abstract side effect, но может иметь concrete side effect:
- https://news.1rj.ru/str/emacsway_log/278
- https://news.1rj.ru/str/emacsway_log/283

3. Кроме Command и Query существуют еще и функции-конструкторы. Накладывается ли на функцию-конструктор ограничение на side effect - зависит от контекста применения:
- https://news.1rj.ru/str/emacsway_log/281

4. B.Meyer считал, что Command не должен возвращать служебную информацию об успешности принятия и выполнения Command потому, что в то время не располагал такими механизмами, которые имеются в нашем распоряжении сегодня:
- https://news.1rj.ru/str/emacsway_log/279

5. Предыдущий пункт возникает именно из-за того, что команды, возвращающие значение, по мнению самого B.Meyer, все-таки могут быть:
- https://news.1rj.ru/str/emacsway_log/279

6. Основная обязанность, которую Query отбирает у Command - это возврат информации об объекте. Мейер не говорит ничего о том, что делать со служебной информацией, которая не касается состояния самого объекта, за исключением случая, описанного в п.4:
- https://news.1rj.ru/str/emacsway_log/280

7. Процедура не возвращает значения, но может изменить объект, переданный аргументом по ссылке. Эту возможность широко использует паттерн Notification.
- https://news.1rj.ru/str/emacsway_log/284

8. Для разделения атомарных операций Command и Query (list.pop()) используется коцепция буффера:
- https://news.1rj.ru/str/emacsway_log/284

9. Пункты 7 и 8 находят свое отражение в Asynchronous Request-Reply pattern:
- https://news.1rj.ru/str/emacsway_log/284

10. Существует требование RFC-7231, которое гласит, что при создании объекта методом POST, сервер должен вернуть идентификатор созданного ресурса. И здесь уместно вспомнить про функции-конструкторы:
- https://news.1rj.ru/str/emacsway_log/282

11. Reference Transparency открывает все выгоды использования Functional Programming, что становится особенно востребованным в распределенной среде:
- https://news.1rj.ru/str/emacsway_log/264

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

Неплохое сравнение Go и Rust в примерах:
https://programming-idioms.org/cheatsheet/Go/Rust

#FunctionalProgramming #StructuredProgramming #ImperativeProgramming #OOP

Хорошая статья про CQRS:
"Types of CQRS" by Vladimir Khorikov
- https://enterprisecraftsmanship.com/posts/types-of-cqrs/

Обратите внимание на комментарии внизу статьи - ее прорецензировал собственноручно Greg Young - автор термина CQRS.

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

📝 "Grady Booch has also provided a set of guidelines for an agile architecture (which in turn imply some duties for the agile architect). Booch claims that all good software-intensive architectures are agile. What does he mean by this? He means that a successful architecture is resilient and loosely coupled. It is composed of a core set of well-reasoned design decisions but still contains some “wiggle room” that allows modifications to be made and refactorings to be done, without ruining the original structure.

Booch also notes that an effective agile process will allow the architecture to grow incrementally as the system is developed and matures. The key to success is to have decomposability, separation of concerns, and near-independence of the parts. (Sound familiar? These are all modifiability tactics.)

Finally, Booch notes that to be agile, the architecture should be visible and self-evident in the code; this means making the design patterns, cross-cutting concerns, and other important decisions obvious, well communicated, and defended. This may, in turn, require documentation. But whatever architectural decisions are made, the architect must make an effort to “socialize” the architecture."

- "Software Architecture in Practice" 3d edition by Len Bass, Paul Clements, Rick Kazman

📝 "If I were a system administrator looking to learn a new programming language it would be Go.

So many of our tools including Kubernetes, Prometheus, and Terraform are written, and extended, in Go that it's almost a requirement next to learning Bash."
- Kelsey Hightower
https://twitter.com/kelseyhightower/status/1336097427586129920?s=19

Вернемся к вопросу о возврате ID созданного ресурса в ответ на POST запрос REST-API. Как говорилось ранее ( https://news.1rj.ru/str/emacsway_log/282 ), RFC-7231 требует, чтобы REST API вернул идентификатор созданного ресурса в ответ на HTTP POST запрос.

Какие вообще есть альтернативы?

📝 "If the data is needed by the client as soon as it is submitted, it is there – on the client that submitted it. No need to poll the query side. The only thing that might not have been there is an ID from the database – which is easily solved with client-generated GUIDs instead of database-generated IDs."
- "Clarified CQRS" comment 68 of Udi Dahan
http://udidahan.com/2009/12/09/clarified-cqrs/#comment-5118

Идентификатор может быть сгенерирован на стороне клиентского приложения, используя UUID ( https://en.wikipedia.org/wiki/Universally_unique_identifier ), Hi/Lo algorithm ( https://en.wikipedia.org/wiki/Hi/Lo_algorithm ) и т.п. После этого, ресурс может быть создан посредством PUT Request Method:

📝 "The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload. <...> If the target resource does not have a current representation and the PUT successfully creates one, then the origin server MUST inform the user agent by sending a 201 (Created) response."
- "Section 4.3.4. PUT of RFC-7231"
https://tools.ietf.org/html/rfc7231#section-4.3.4

Другим вариантом, как говорилось ранее ( https://news.1rj.ru/str/emacsway_log/284 ), может быть "Asynchronous Request-Reply pattern" ( https://docs.microsoft.com/en-us/azure/architecture/patterns/async-request-reply ), использующий 202 Response Status Code ( https://tools.ietf.org/html/rfc7231#section-6.3.3 ).

Но действительно ли нам нужно получать идентификатор в ответ на команду? Часто такая потребность возникает просто из-за недостаточного понимания тех выгод, которые предоставляет CQS и Referential Transparency - однонаправленный поток изменений и единственный источник истины.

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

Referential Transparency означает, что вызов функции можно многократно повторять без какого-либо ущерба, и она всегда будет возвращать один и тот же результат.

Более того, - возникает возможность легко управлять потоком изменений, сделав его однонаправленным, и сформировав единственный источник истины (single source of truth - один из ключевых принципов Redux https://redux.js.org/understanding/thinking-in-redux/three-principles , который следует принципам CQRS https://redux.js.org/understanding/thinking-in-redux/motivation ). Это существенно облегчает создание сложных приложений, используя Task Based UI, позволяет легко организовать репликацию и кэширование, устранить задержки. Подробнее эти вопросы хорошо раскрывает Udi Dahan в монументальной статье "Clarified CQRS":
http://udidahan.com/2009/12/09/clarified-cqrs/

Статья доступна для скачивания в формате pdf:
https://udidahan.com/wp-content/uploads/Clarified_CQRS.pdf

Представьте, что пользователь добавил в корзину последний товар, используя совмещенную операцию Команды и Запроса. В ответ на Команду, сервер сообщил, что товар снят с продажи. Клиентское приложение пользователя обновило свое состояние, и заблокировало в UI возможность заказать уже недоступный товар.

Я намеренно примитивизирую ситуацию - на самом деле она гораздо более сложнее в распределенных системах:
- https://youtu.be/fWU8ZK0Dmxs
- хороший пример с overbooking в книге https://martinfowler.com/books/nosql.html

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

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

Сюда можно добавить еще время, требуемое на обновление реплик чтения.

📝 "Staleness refers to the fact that in a collaborative environment, once data has been shown to a user, that same data may have been changed by another actor – it is stale. Almost any system which makes use of a cache is serving stale data – often for performance reasons. What this means is that we cannot entirely trust our users decisions, as they could have been made based on out-of-date information."
- "Clarified CQRS" by Udi Dahan
https://udidahan.com/2009/12/09/clarified-cqrs/

Отделение Команд от Запросов позволяет организовать однонаправленный поток изменений, и тогда оба пользователя одновременно получат сообщение о событии, что последний товар закончился.
https://udidahan.com/wp-content/uploads/cqrs.png

📝 "After the command-processing autonomous component has decided to accept a command, modifying its persistent store as needed, it publishes an event notifying the world about it."
- "Clarified CQRS" by Udi Dahan
https://udidahan.com/2009/12/09/clarified-cqrs/

📝 "CQRS is about coming up with an appropriate architecture for multi-user collaborative applications. It explicitly takes into account factors like data staleness and volatility and exploits those characteristics for creating simpler and more scalable constructs."
- "Clarified CQRS" by Udi Dahan
https://udidahan.com/2009/12/09/clarified-cqrs/

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

Теперь, понимая важность однонаправленного потока изменений в условиях collaborative evironment, нам становится легче понять разницу между abstract side effect и concrete side effect.

В этом видео Udi Dahan использовал термин sandbox:
https://youtu.be/fWU8ZK0Dmxs

Часто ресурс начинает создаваться как черновик. Он не доступен никому через публичный интерфейс, кроме его автора. Никто не должен знать о его существовании, кроме его автора. И если мы нарушим здесь CQS, то никто этого не заметит. На ресурс распространяется concrete side effect:
- https://news.1rj.ru/str/emacsway_log/278
- https://news.1rj.ru/str/emacsway_log/283

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

Такой же вывод возникает и из принципа функции-конструктора: до тех пор, пока ресурс не принадлежит ни к одной из публичных коллекций, доступной остальным пользователям, side effect не имеет последствий:
- https://news.1rj.ru/str/emacsway_log/281

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

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

Ответ 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

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