akka-persistence-eventsourcing
akka-persistence-eventsourcing copied to clipboard
ScalaConsultants
Possible design improvement 2
This PR is connected with my promise to adjust code to blog http://blog.zilverline.com/2011/02/02/towards-an-immutable-domain-model-%E2%80%93-immutable-change-part-2/
Unfortunately (IMO) it make no sense to directly implement ideas from blog http://blog.zilverline.com/2011/02/02/towards-an-immutable-domain-model-%E2%80%93-immutable-change-part-2/ because:
- AR from blog is accepting events instead of commands. IMO your approach is better because I think only AR knows which event (events) should be produced for each command, so I wouldn't change it. So all this ideas connected with monads and events make no sens for your solutions (IMO again)
- uncommittedEvents make no sense in case of AR because AR should do whole transaction so there is no need to hold some data of this kind, from the other hand all infrastructure connected with akka-persistent and ARActor is handling all things which could be handled by uncommittedEvents
- Validation can be handled in a few different ways than described in blog (eg by sending validation connected events) so I doubt it should be done in a way described in blog
- The way in which state pattern is used in blog is very risky. Normally in state pattern client is using general interface of transitions for all concrete states, in blog client is using concrete state. It is risky because that way state machine internals are exposed to the client, also client have to know which event should be send to which state, for me it is just bad design.
- AR in blog doesn't have separate state object
So I decided to do it in a way which is more inspired by this blog than strict implementation of it. Also I decided to make a way in which AR is implemented totally independent from ARActors* so I introduced AggregateRootAdapter which allows to implement connection with actor in a needed way. Now AR may be implemented as methods in State, or like it is in blog by using state pattern or (like I did it) purely functional by using objects with functions. It is just a matter of implementing proper adapter. It is possible to have different adapters for different ARs.
I choose to implement it purely functional because it is really strange to have a state as a separate object and have some additional object AR which has this state and have to be changed every time this state is changing to have it immutable. IMO it is much more natural to just have a functions in this case.
Edited: Generics added AR separated from ARActor.
This time I pushed intentionally to this branch after introducing this PR. I've just learned how to use pattern matching against generic, so it was possible to use generics in ARA code instead of concrete types, which allowed me to separate AR from ARA totally.
