Skip to main content
Added paywall information about Pluralsight link cc @ThomasOwens.
Source Link
kayess
  • 241
  • 4
  • 12

All this above is nothing new. I like to call this CQRS Lite - a term I have borrowed from Dino Esposito. He has a very comprehensive tutorial course on this at PluralSight. I wholeheartedly recommend that you watch it there, as there is a lot to learn from him. [1]

[1] It must be noted here that this course is behind a paywall, it means you need to pay money to watch it, and I would like to make it clear that I'm not affiliated with PluralSight in any ways.

All this above is nothing new. I like to call this CQRS Lite - a term I have borrowed from Dino Esposito. He has a very comprehensive tutorial course on this at PluralSight. I wholeheartedly recommend that you watch it there, as there is a lot to learn from him.

All this above is nothing new. I like to call this CQRS Lite - a term I have borrowed from Dino Esposito. He has a very comprehensive tutorial course on this at PluralSight. I wholeheartedly recommend that you watch it there, as there is a lot to learn from him. [1]

[1] It must be noted here that this course is behind a paywall, it means you need to pay money to watch it, and I would like to make it clear that I'm not affiliated with PluralSight in any ways.

EDIT 1: to To answer the question you asked in a comment, syncing really depends on your actual architecture. I, for one, am really against pushing code out to external sources (e.g. triggers, batch jobs) if possible. I prefer the inverse: push all code as deep as possible into my own implementations (over which I have direct control). As stated, I'm using commands, events, and queries for data manipulation.

EDIT 2: your Your question about "what if the event handler dies"dies?" is gong to make this a bit more complex, by introducing new concepts called Eventual consistencyConsistency and message/event queueingqueuing. Quoting Greg Young:

This concept extends all abovethis answer with:

  • a place to store all events that happened on the write side
  • have a queue that goes through these stored events and apply itapplies them to the read side

EDIT 1: to answer the question you asked in a comment, syncing really depends on your actual architecture. I, for one, am really against pushing code out to external sources (e.g. triggers, batch jobs) if possible. I prefer the inverse: push all code as deep as possible into my own implementations (over which I have direct control). As stated, I'm using commands, events, and queries for data manipulation.

EDIT 2: your question about "what if event handler dies" is gong to make this a bit more complex, by introducing new concepts called Eventual consistency and message/event queueing. Quoting Greg Young:

This concept extends all above with:

  • a place to store all events happened on write side
  • have a queue that goes through these stored events and apply it to the read side

To answer the question you asked in a comment, syncing really depends on your actual architecture. I, for one, am really against pushing code out to external sources (e.g. triggers, batch jobs) if possible. I prefer the inverse: push all code as deep as possible into my own implementations (over which I have direct control). As stated, I'm using commands, events, and queries for data manipulation.

Your question about "what if the event handler dies?" is gong to make this a bit more complex, by introducing new concepts called Eventual Consistency and message/event queuing. Quoting Greg Young:

This concept extends this answer with:

  • a place to store all events that happened on the write side
  • a queue that goes through these stored events and applies them to the read side
added 526 characters in body
Source Link
kayess
  • 241
  • 4
  • 12

EDIT:EDIT 1: to answer the question you asked in a comment, syncing really depends on your actual architecture. I, for one, am really against pushing code out to external sources (e.g. triggers, batch jobs) if possible. I prefer the inverse: push all code as deep as possible into my own implementations (over which I have direct control). As stated, I'm using commands, events, and queries for data manipulation.

  • Since we adhere to Command Query Separation, we can easily decorate point 2 with command authorisation, validation, logging, etc. without actually modifying the code in the Controller or the command handler.
  • As you may have noticed, we struggle to keep parts of this subsystem as decoupled and testable as possible. Also, the concerns are blindingly separated.

EDIT 2: your question about "what if event handler dies" is gong to make this a bit more complex, by introducing new concepts called Eventual consistency and message/event queueing. Quoting Greg Young:

On most systems you can just use a queue as the read system will want pretty much every event from the write system anyways.

This concept extends all above with:

  • a place to store all events happened on write side
  • have a queue that goes through these stored events and apply it to the read side

EDIT: to answer the question you asked in a comment, syncing really depends on your actual architecture. I, for one, am really against pushing code out to external sources (e.g. triggers, batch jobs) if possible. I prefer the inverse: push all code as deep as possible into my own implementations (over which I have direct control). As stated, I'm using commands, events, and queries for data manipulation.

  • Since we adhere to Command Query Separation, we can easily decorate point 2 with command authorisation, validation, logging, etc. without actually modifying the code in the Controller or the command handler.
  • As you may have noticed, we struggle to keep parts of this subsystem as decoupled and testable as possible. Also, the concerns are blindingly separated.

EDIT 1: to answer the question you asked in a comment, syncing really depends on your actual architecture. I, for one, am really against pushing code out to external sources (e.g. triggers, batch jobs) if possible. I prefer the inverse: push all code as deep as possible into my own implementations (over which I have direct control). As stated, I'm using commands, events, and queries for data manipulation.

  • Since we adhere to Command Query Separation, we can easily decorate point 2 with command authorisation, validation, logging, etc. without actually modifying the code in the Controller or the command handler.
  • As you may have noticed, we struggle to keep parts of this subsystem as decoupled and testable as possible. Also, the concerns are blindingly separated.

EDIT 2: your question about "what if event handler dies" is gong to make this a bit more complex, by introducing new concepts called Eventual consistency and message/event queueing. Quoting Greg Young:

On most systems you can just use a queue as the read system will want pretty much every event from the write system anyways.

This concept extends all above with:

  • a place to store all events happened on write side
  • have a queue that goes through these stored events and apply it to the read side
Typo and wording fixage, thanks to @TigerhawkT3
Source Link
kayess
  • 241
  • 4
  • 12
Loading
added 1494 characters in body
Source Link
kayess
  • 241
  • 4
  • 12
Loading
Added links to examples
Source Link
kayess
  • 241
  • 4
  • 12
Loading
Source Link
kayess
  • 241
  • 4
  • 12
Loading