EJSarge (7) [Avatar] Offline
Following on from my previous question, I'm attempting to apply some of these principles in my application. One stumbling block I have is that what my application does is mostly side effects: tell some other system to do something, process the results, email the results off and update a database to track state.

In such a situation the Reader monad doesn't seem quite right - I have multiple state transitions of the same aggregate root. How does one structure this? The Martin Krasser blog links promise to discuss this but never do.

Similarly, when using the Reader monad with a number of dependences (i.e. > 1) do you pass them all in individually or create some kind of context object to carry the references?
Debasish Ghosh (111) [Avatar] Offline
For handling side-effects you need to use monads like IO or State. I discuss monads in general and applications of the State monad in domain modeling in chapter 4, which is still with the publisher for review. You will get all the details when it's MEAPed very soon.

There's another technique for purifying code from side-effects, which goes by the name of Free Monads. Using this technque, you can segregate your code into the pure parts (which we call the algebra) and the impure interpreters (which we call implementation). I will discuss this in detail in chapter 5, which is still in the labs. For an introduction to Free Monads you can have a look at this post from Gabriel (http://www.haskellforall.com/2012/07/purify-code-using-free-monads.html).

Regarding multiple injectables with Reader monad, your approach looks ok. Create some kind of context object with all the dependencies and inject them using Reader Monad. I will explore this in some exercise in chapter 3. BTW the exercises are still in the labs and will be included in the book later on.

Hope this clarifies your questions. Feel free to ask more as we progress through the book.