Free AI web copilot to create summaries, insights and extended knowledge, download it at here

Abstract

m a discussion about <b>intent </b>to cause domain events. I describe “domain commands” as domain relevant historical facts, which promise task execution flows to bring about new domain events. Such flows may be widely distributed and are just semantically coupled.</p><h2 id="3344">September 17th 2018: Aggregates and sagas are processes</h2><figure id="da68"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*RlzkxtNaohq4vf7PJ8duAQ.jpeg"><figcaption></figcaption></figure><p id="c4ab">Being so close relatives, all domain facts are very much on eye level with each other … and this has potential to evolve the way I look at aggregates and their working relationships with sagas and process managers: Aggregates leverage domain commands in just about the same way they leverage domain events.</p><h2 id="b82f">September 23rd 2018: The distributed execution of processes</h2><figure id="f76f"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*t0tZa6Q5xRkZF7YoYcvMfQ.jpeg"><figcaption></figcaption></figure><p id="c51c">One can see a perfect aggregate in a <b>task. </b>It’s a little state machine with states like created, completed, failed and more. Furthermore, tasks can be nested: to complete a task we might need to complete several sub tasks. However if we try to put tasks into a locally consistent box we run into troubles.</p><h2 id="c9ad">Possible stop: Events</h2><p id="f24a">Do the “domain commands” I describe taste like domain events? <i>Are</i> both just plain events? In a way, yes! But it’s often language causing the confusion. Is it helpful to call both just facts or to even speak about fact-driven architectures? It’s just leveraging pub/sub, but much more explicitely considering semantics.</p><h2 id="b33e">Possible stop: Bounded contexts</h2><p id="1280">Starting from the very loose semantical coupling we know from events I feel we can “go even looser” by distinguishing who defines and who creates them. While domain event emitters do not need to know about listening consumers, domain command suppliers do not know about command issueing parties.</p><h2 id="f56b">Possible stop: Queries and reports</h2><p id="b38b">Similar to commands and events, queries and reports can also be described as flavours of domain relevant facts. All together they drive potentially widely distributed, just loosely semantically coupled execution flows. Furthermore: how does CQRS (Command Query Responsibility Segregation) fit into that?</p><h2 id="9f9a">Possible stop: Eventsourcing</h2><p id="07ca">When I distinguish a few event categories and call them “facts”, I can ofc also “factsource” all of them. While this may resemble “command sourcing”, it has nothing to do with the concept, as historically discussed: the sourcing doesn’t happen at a place of execution, but at a place where intent originally occurs.</p><h2 id="abb0">Possible stop: Orchestration and choreography</h2><p id="081f">Leveraging domain event and com

Options

mand semantics enables wildly distributed business processes which can combine advantages of both “choreographed” and “orchestrated” approaches, and can avoid most of their downsides. We may both stop bashing orchestration <i>and </i>wish<i> </i>choreographies a long life?</p><h2 id="9c36">Possible stop: Idempotency</h2><p id="663f">“Factsourcing” all types of domain facts can enable a very robust level of “total” idempotency across communicating services. Provided all facts systematically know about their causes, handlers can digest their own fact history, decide to ignore duplicates, or to redeliver facts without worrying to cause any harm.</p><h2 id="0a33">Possible stop: Cancellation and compensation</h2><p id="31fe">A useful abstraction for domain facts brings more transparence into execution flows going across different services or systems. Domain commands can directly specify via which domain events their execution progresses, how those can be correlated and how executions can be cancelled or compensated.</p><h1 id="7134">Why could you choose to care?</h1><p id="3dde">I<b> </b>will try to discuss: why does all this matter for strategic domain-driven design (DDD)? It does affect context boundaries and system autonomy. Why does it matter for modeling, e.g. using EventStorming? It affects the quality of communications between domain experts and developers. Why does it matter for message- and in particular event-driven architectures (EDA)? I believe those approaches have almost all the ingredients to success, but with a little help by even more meaningful ways to speak about possible event and fact semantics, they will (eventually) “eat the world”. Last not least, why does all this matter for a discussion of DDD’s “aggregates”? I feel, by some they are nowadays interpreted as alienated “workers”: handling commands, raising events, not caring much how to make clients happy. This doesn’t feel quite right. Aggregates as I envision them have the ability to carry out work <b>and</b> to autonomously decide to outsource things and manage the needed workflows.</p><p id="b122">Some motivation to read on? :-) Then let’s get this discussion started.</p><p id="1499">A small, but important thing … even when I sound assertive sometimes, it’s a subconcious technique I use to provoke <b>your</b> associations and counter arguments. I never claim to understand, but always try to understand better than before. I share <b>thoughts and feelings</b>, and even when I attempt to “define” things, it’s an invitation: please help me, as a software community, to <b>eventually </b>get this stuff<b> consistent</b>! :-) If you want to keep in touch, you can <a href="https://twitter.com/martinschimak">follow me on Twitter</a>. It’s also the simplest way in case you need to exchange a direct message with me. Thank you for reading and spending some of your precious time with me. For me it’s the most precious thing you can share.</p></article></body>

My Fact-Driven Journey

2018 With this post I kick off a little series of posts. I want to shine light on commands and events, also queries and reports. I plan to describe them as flavours of domain facts driving potentially widely distributed, just semantically and loosely coupled execution flows. I feel a discussion of this mental model might improve my understanding of event-driven architectures, domain-driven design and associated patterns like event sourcing and CQRS.

Originally I thought I will write one post or article and then I’m done! :-) But now I know that I will need a series of posts, and because I do have experience with “development”, I also know that I will drive the streets based on new facts and your considerations.

I hope to get your feedback to eventually get this stuff consistent!

The current plan for my journey

In my backpack: A Little Chatbot For Schools

This little scenario will be used in some examples on my journey.

It’s Monday morning 8am and a school principal’s phone rings. One of her teachers reports to be “knocked out” and sick for up to three days. The principal looks at the teacher’s time table in order to arrange for the very first lesson. It’s a mathematics lesson which already starts in half an hour! Better be taken care of …

August 9th 2018: Business rules

I have “been there and done that”! And: KaBoom! Sessions, hikings, pool discussions, lunches, dinner conversations… almost everything around the EventStorming Summit 2018 in Bologna, Italy resonated with what I talk and think about since some time now. So I decided to start to write about it.

In this post I suggest to “reclaim” the large, yellow stickies to model business rules.

August 23rd 2018: Commands

In this post I suggest to think about commands as domain relevant historical facts.

I feel that I and maybe “we” (as a software community) could profit from a discussion about intent to cause domain events. I describe “domain commands” as domain relevant historical facts, which promise task execution flows to bring about new domain events. Such flows may be widely distributed and are just semantically coupled.

September 17th 2018: Aggregates and sagas are processes

Being so close relatives, all domain facts are very much on eye level with each other … and this has potential to evolve the way I look at aggregates and their working relationships with sagas and process managers: Aggregates leverage domain commands in just about the same way they leverage domain events.

September 23rd 2018: The distributed execution of processes

One can see a perfect aggregate in a task. It’s a little state machine with states like created, completed, failed and more. Furthermore, tasks can be nested: to complete a task we might need to complete several sub tasks. However if we try to put tasks into a locally consistent box we run into troubles.

Possible stop: Events

Do the “domain commands” I describe taste like domain events? Are both just plain events? In a way, yes! But it’s often language causing the confusion. Is it helpful to call both just facts or to even speak about fact-driven architectures? It’s just leveraging pub/sub, but much more explicitely considering semantics.

Possible stop: Bounded contexts

Starting from the very loose semantical coupling we know from events I feel we can “go even looser” by distinguishing who defines and who creates them. While domain event emitters do not need to know about listening consumers, domain command suppliers do not know about command issueing parties.

Possible stop: Queries and reports

Similar to commands and events, queries and reports can also be described as flavours of domain relevant facts. All together they drive potentially widely distributed, just loosely semantically coupled execution flows. Furthermore: how does CQRS (Command Query Responsibility Segregation) fit into that?

Possible stop: Eventsourcing

When I distinguish a few event categories and call them “facts”, I can ofc also “factsource” all of them. While this may resemble “command sourcing”, it has nothing to do with the concept, as historically discussed: the sourcing doesn’t happen at a place of execution, but at a place where intent originally occurs.

Possible stop: Orchestration and choreography

Leveraging domain event and command semantics enables wildly distributed business processes which can combine advantages of both “choreographed” and “orchestrated” approaches, and can avoid most of their downsides. We may both stop bashing orchestration and wish choreographies a long life?

Possible stop: Idempotency

“Factsourcing” all types of domain facts can enable a very robust level of “total” idempotency across communicating services. Provided all facts systematically know about their causes, handlers can digest their own fact history, decide to ignore duplicates, or to redeliver facts without worrying to cause any harm.

Possible stop: Cancellation and compensation

A useful abstraction for domain facts brings more transparence into execution flows going across different services or systems. Domain commands can directly specify via which domain events their execution progresses, how those can be correlated and how executions can be cancelled or compensated.

Why could you choose to care?

I will try to discuss: why does all this matter for strategic domain-driven design (DDD)? It does affect context boundaries and system autonomy. Why does it matter for modeling, e.g. using EventStorming? It affects the quality of communications between domain experts and developers. Why does it matter for message- and in particular event-driven architectures (EDA)? I believe those approaches have almost all the ingredients to success, but with a little help by even more meaningful ways to speak about possible event and fact semantics, they will (eventually) “eat the world”. Last not least, why does all this matter for a discussion of DDD’s “aggregates”? I feel, by some they are nowadays interpreted as alienated “workers”: handling commands, raising events, not caring much how to make clients happy. This doesn’t feel quite right. Aggregates as I envision them have the ability to carry out work and to autonomously decide to outsource things and manage the needed workflows.

Some motivation to read on? :-) Then let’s get this discussion started.

A small, but important thing … even when I sound assertive sometimes, it’s a subconcious technique I use to provoke your associations and counter arguments. I never claim to understand, but always try to understand better than before. I share thoughts and feelings, and even when I attempt to “define” things, it’s an invitation: please help me, as a software community, to eventually get this stuff consistent! :-) If you want to keep in touch, you can follow me on Twitter. It’s also the simplest way in case you need to exchange a direct message with me. Thank you for reading and spending some of your precious time with me. For me it’s the most precious thing you can share.