I'm not an expert and still learning how to design systems using this approach.
Here are some suggestions: 1. If you design your domain using DDD properly you will end up with a reasonable set of aggregates, entities and value objects. You should design your events to mirror your business processes. I personally feel DDD requires more investment and skills but if you get it right you can avoid a lot of complexity afterwards. 2. Even if your core events don't change you may need to add information later which effectively changes your event resulting in a new version. Something like this is likely to happen at initial stages of your project when the business concepts are are still in flux. One way to address this is to replay the old events from start and create a new set of events with the new version. I would also be very interested to hear what others have to say on this. -Soumya On Sunday, January 11, 2015 at 1:56:01 PM UTC-5, Robert Budźko wrote: > > Hi, > > Recently, I've been playing with persistent actors a little bit. I've > decided to design my PoC in such a way that some actors are distributed > entities (state holders). Usually, not persistent actor supervises a group > of entity-actors (of the same type) and asks them to handle commands > (usually changing the state). I was delighted with this approach in the > first place, but now I doubt my design, because I've encountered problem of > migration when persistent actor is being developed/refactored, so both > commands and events are changed. Additionally, I'm a little bit unhappy > because of serialization in form of "blob". > > I got couple of ideas how to solve my problem but non of them is > convincing me 100%: > 1) Prepare custom serializer which is able to serialize my events into for > example relational model, so I can migrate database when implementation of > event is changed (benefit). In this case, I don't like the fact that I have > to add serialization implementation for each new agent. > 2) I was thinking about recognition of event version in serializer and > having all versions of events in classpath, so it will sustain backward > compatibility. I'm not even sure if it is possible (have not confirmed it > yet). I'm also afraid that code might become nasty after couple of versions. > 3) I wonder if it is possible to somehow snapshot state into latest > version so, after next start of node, old versions of events are not > required any more. > > Problems I'm trying to solve are: > 1) Possibility of migration of persisted state. (ie. executing sql in > relational database) > 2) Possibility of accessing state w/o deserialization into event class. > (ie. peeking into relational database). > > Do you know any patterns, approaches which could lead to solution of those > problems? Maybe my design is not valid in the end :-] . > > Thank you, > Robert > > PS Relational database was used as an example of different storage then > default one. It can by any different storage. > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
