Skip to content

Links & notes from my way to domain driven design, CQRS and event sourcing.

Notifications You must be signed in to change notification settings

jkuchar/ddd-crqs-event-sourcing-notes

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

48 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Event-Sourcing basic example app

Aim: learn basics of event sourcing pattern and its caveats.

This project builds on an example from the presentation from Mathias Verraes - Practical Event Sourcing.

gitlab.grifart.cz repo github mirror

Learning DDD (Domain Driven Design)

Bellow is learning material that I have used to dive into event DDD (and its implementations) deeper.

The Strategic Design

I have put DDD in its own section because DDD is more an analysis process than a collection of structural patterns.

Case studies

Pragmatism

The Technical Stuff

This section describes how people are implementing their domains. Be careful. Always make sure you know why author of talk decided to do his thing that way.

Cannot stress enough that DDD does NOT have just a technical part. It is more style of thinking that you need to learn by shifting you mind. (see the first section of this document)

Keep it simple

Event Sourcing + CQRS

An alternative implementation of domain model persistence layer which stores a complete history of all events that happened in the domain in the past.

Hexagonal architecture

  • Layers & ports and adapters - part 1, 2 and 3

(The structural part of) DDD in PHP

Message Buses/libraries

Process Managers / Sagas (the same thing!)

Examples

Notes / TODOs

  • How to make a proper relation between Product and Basket?
    • Answer: Analyse bounded contexts. (probably in most domains use two separate AggregateRoots)
  • How to access product name when product-related event occurs - aggregate does not expose any state?! (should I access read model from write model?)
    • Answer: Access read side if needed or use heavy events.
  • If aggregate produces event but it does not change state in any way, should it have empty apply() method for this event or should framework just skip this event. (this can lead into hard discoverable typo errors)
    • Answer: I would prefer to hot have this methods in aggregate and have some kind of static analysis check for method name and type consistency (in PHP which does not support method overloading).
  • Is there any point of adding events when loading from history into the object "recorded events"?
    • Answer: No, if you load them there, they will be persisted once more and there will be a need for merge process.

About

Links & notes from my way to domain driven design, CQRS and event sourcing.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages