It was an interesting time to go through this experiment. The goal was to reimplement Ruby experiment in python. Then to check which approach is interesting to use in production projects. I reimplemented 7/10 of them. Here is the list: AggregateRoot Exposed queries Extracted state Functional Polymorphic Duck Typing Repository I didn’t see much benefit … Read more
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
DDD Aggregate is responsible for encapsulating business logic for the component. But we need to be aware that when we are implementing business logic for a long time process that is coordinating many components, like subscription trial, we have another building block for this. It’s a process manager. Below I pointed out some differences between … Read more
