Luke On Python

This post is seventh experiment described in post “Experiment: 10 Different implementations of Aggregate“. This one is very similar to the classical example. The goal is to separate more from an event-sourcing framework and making the Repository implemented for actual Aggregate. Reflections on this experiment I don’t see many benefits from this example. In this … Read more

This post is sixth experiment described in post “Experiment: 10 Different implementations of Aggregate“. This experiment is the same as the previous one, but without inheriting or describing the protocol/interface for the issue. So the goal is to have separate domain objects per state, no id or messaging inside the domain part. Exception of invalid … Read more

This post is fifth experiment described in post “Experiment: 10 Different implementations of Aggregate“. The goal of this experiment is to have separate objects for every state of issue. There is no id in domain classes, not shared state. Also, domain classes are not creating domain events. Reflections on this experiment I like this approach, … Read more

This post is fourth experiment described in post “Experiment: 10 Different implementations of Aggregate“. Goal of this experiment was to remove single AggregateRoot and use functions instead. Reflections on this experiment Seeing the name “functional” I expected something different. Maybe use monads or something like this. Here we have some objects that are basic functions … Read more

This post is third experiment described in post “Experiment: 10 Different implementations of Aggregate“. Experiment 3 is passing sourced IssueState into Issue (AggregateRoot). Business logic is handled by Issue and Issue is emitting domain events. Reflections on this experiment This one seems to be overcomplicated for me. I guess the benefits are in processing events … Read more

This post is second experiment described in post “Experiment: 10 Different implementations of Aggregate“. This implementation assumed that aggregate is created from a projection of events. Aggregate is not aware of events or anything about event-sourcing. The responsibility of aggregate is to manipulate internal state and business logic. The interesting part for me is about … Read more

This post is first experiment described in post “Experiment: 10 Different implementations of Aggregate“. This is a classical and most used example of event-sourcing implementation (Greg Young’s CQRS example). It’s dependent on the framework cause of inheritance from the AggregatRoot base class. I like that it don’t have read methods, so all observability is based … Read more

Arkency is a company that shares its experiments with many approaches to DDD aggregate implementation. Some time ago I’ve shared my view on this here. Arkency examples are in Ruby and use an event-sourcing approach. It’s quite different from mine, so some future blog posts will be about reimplementing the Arkency examples in Python. Experiment … Read more