tag:blogger.com,1999:blog-22587889.post7711822270811502612..comments2024-02-11T13:21:47.930+05:30Comments on Ruminations of a Programmer: Event Sourcing, Akka FSMs and functional domain modelsAnonymoushttp://www.blogger.com/profile/01613713587074301135noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-22587889.post-58494265690165526322012-09-23T03:14:22.129+05:302012-09-23T03:14:22.129+05:30Thanks Debasish, I have actually been reading both...Thanks Debasish, I have actually been reading both of your blogs and have been experimenting with various approaches. My particular case is for both a trading system and the configuration for it (web app).Anonymoushttps://www.blogger.com/profile/15573848109245302481noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-68267967690812996212012-09-23T00:45:21.430+05:302012-09-23T00:45:21.430+05:30Hi Gary -
Are u pointing to the fact that we log e...Hi Gary -<br />Are u pointing to the fact that we log events asynchronously and hence leaving a small window of chance that the logging may fail and yet I send notification to my clients ?<br /><br />Yes, that's a problem w/ the current implementation but I wanted to keep things simple to focus on the paradigm itself instead of the implementation details.<br /><br />However, even in a production deployment we would not go for synchronous logging - that would be blocking IO and will kill the scalability. There are other ways to get both the benefits where you need to use an STM and a transient log as well as a persistent log. Martin has blogged on these implementation issues in his series on Event Sourcing. Please check http://krasserm.blogspot.in/2012/01/building-event-sourced-web-application.html for more details.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-77706422391395293062012-09-23T00:31:02.669+05:302012-09-23T00:31:02.669+05:30Hi Debasish,
One question with your implementatio...Hi Debasish,<br /><br />One question with your implementation - in a realistic production system, wouldn't you want to be sure your events were logged prior to processing the state changes and letting clients know that for example their trade has been executed? I feel like you leave yourself open to the small but substantial (in terms of cost) risk of being unable to recreate state if your system goes down and an event had not been logged.<br /><br />Thanks for the great article.Garynoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-61974690263366006602012-05-25T17:27:16.323+05:302012-05-25T17:27:16.323+05:30Thanks ....nice stuff...great articleThanks ....nice stuff...great articleDomain Registration Chennaihttp://techbee.co.in/domain-registration-chennai/noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-59104841539041990152012-01-18T11:01:55.820+05:302012-01-18T11:01:55.820+05:30I meant that we should have domain services to man...I meant that we should have domain services to manage the lifecycle and state transitions of all domain objects. For database persistence we usually do it through the Repository. In this case for managing the states of a domain object we can use the FSM. The point that I was trying to make in the post is that why not make the FSM explicit - so now we have clear declarative code that documents the events and states very explicitly.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-65744371241863131542012-01-18T02:14:23.892+05:302012-01-18T02:14:23.892+05:30Yes I see what you are saying. Of course I wouldn&...Yes I see what you are saying. Of course I wouldn't put the save on the Trade. I think I make a distinction between 'pure' domain specific behaviour which lives on the Trade, versus systemic functions like persistence. I realise that is very vague and imprecise.<br /><br />When you say 'it's the responsibility of a service object to manage it's transitions', did you mean that it's the responsibility of a separate service object to manage the Trade's transitions? Or, its the Trades responsibility to manage its transitions.Channing Waltonhttps://www.blogger.com/profile/12749648550096851903noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-66198523534301369952012-01-17T12:36:13.184+05:302012-01-17T12:36:13.184+05:30That's one way to look into it. But consider, ...That's one way to look into it. But consider, if you were to save a Trade object to the database, will u put the save() method in Trade. By your logic, you should because the Trade object should know how to persist itself. This can make the Trade abstraction bloated. Just like it's the responsibility of a DAO to persist a Trade object, I claim that similarly it's the responsibility of a service object to manage it's transitions. The Trade object will move through various states as implied from the values of it's various fields. And as long as we manage this movement keeping it immutable, I think we are done.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-38825749316601305382012-01-17T12:28:01.363+05:302012-01-17T12:28:01.363+05:30Hi,
> Why should the *state* field and the *upd...Hi,<br />> Why should the *state* field and the *update* method exist on the Trade object ? <br /><br />Well. There lies hours of debate :D My OO brain says push behaviour into objects, the Trade 'should' know how to update itself and what its interested in in the domain of this app. <br /><br />I used to be very certain about these things. I am not young enough to be so certain any more ;)Channing Waltonhttps://www.blogger.com/profile/12749648550096851903noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-68278880215433480442012-01-16T10:59:22.554+05:302012-01-16T10:59:22.554+05:30@Channing Walton
You are correct! We end up imple...@Channing Walton<br /><br />You are correct! We end up implementing FSMs most of the time without knowing beforehand. <br /><br />I am a bit of a fanatic on domain abstractions being *pure*. Why should the *state* field and the *update* method exist on the Trade object ? Is it part of the domain in the real world ? Hence I took this approach of externalizing the whole FSM outside the Trade abstraction.<br /><br />But again, designs are never wrong or right .. if it works for you it's great :-) .. <br /><br />Cheers.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-20323310317375297242012-01-16T03:52:13.706+05:302012-01-16T03:52:13.706+05:30Hi Debasish,
thanks for this article, more food fo...Hi Debasish,<br />thanks for this article, more food for thought.<br /><br />I recently modelled state transitions for Trades as follows. A (immutable) Trade has a state as a field, modelled as case classes. State transitions are made by calling a method on Trade: update(event:SomeEvent):Option[Trade] = state.update(this, event)<br /><br />The state is responsible for transitioning the trade and optionally creating a new trade with a new state. There are cases where there is no transition in response to an event for a number of reasons, hence the Option. In some scenarios there may be a need to return an error (Either or scalaz Validation), but not in my case.<br /><br />This approach enables each State to encapsulate the knowledge about what the valid transitions to other states are.<br /><br />I suspect that this design represents a FSM albeit implicitly. Maybe thats a problem?Channing Waltonhttps://www.blogger.com/profile/12749648550096851903noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-10059594924360591952012-01-16T03:48:07.447+05:302012-01-16T03:48:07.447+05:30Hi Debasish,
thanks for this article, more food fo...Hi Debasish,<br />thanks for this article, more food for thought.<br /><br />I recently modelled state transitions for Trades as follows. A (immutable) Trade has a state as a field, modelled as case classes. State transitions are made by calling a method on Trade: update(event:SomeEvent):Option[Trade] = state.update(this, event)<br /><br />The state is responsible for transitioning the trade and optionally creating a new trade with a new state. There are cases where there is no transition in response to an event for a number of reasons, hence the Option. In some scenarios there may be a need to return an error (Either or scalaz Validation), but not in my case.<br /><br />This approach enables each State to encapsulate the knowledge about what the valid transitions to other states are.<br /><br />I suspect that this design represents a FSM albeit implicitly. Maybe thats a problem?Channing Waltonhttps://www.blogger.com/profile/12749648550096851903noreply@blogger.com