@@ -56,6 +56,34 @@ We have just provided a guarantee - at virtually no cost - that
5656persistence concerns can not leak into the ` UserService `
5757implementation.
5858
59+ What if our service method was an effectful method? Perhaps it has to hit another blocking service
60+ somewhere to do its work, such as when hitting another
61+ [ microservice] ( https://www.martinfowler.com/articles/microservices.html ) in the application? In
62+ this case, we would probably be wrapping it in a future-like construct in a reactive setting, or in
63+ an IO monad construct in more of a functional setting. Let's use ` scala.concurrent.Future ` as an
64+ example:
65+
66+ ``` scala
67+ trait UserService {
68+ def updateScoreCard (user : User , event : PointScoredEvent ): Future [User ]
69+ }
70+ ```
71+
72+ We can change our above example to call ` modifyF ` instead of ` modify ` , like so:
73+
74+ ``` scala
75+ val updatedState : Future [PState [User ]] = userState.modifyF { user =>
76+ userService.updateScoreCard(user, event)
77+ }
78+ ```
79+
80+ The persistent state does not inherit the effect from the repository. This means you will have to
81+ make an effect implicitly available when calling ` modifyF ` , in the same way as when you [ created
82+ your longevity context] ( ../context/effect.html ) . (The persistent state could easily inherit the
83+ effect from the repository, and perhaps it should. The advantage of inheriting the effect is that
84+ the user would not need to supply the effect again when calling ` modifyF ` . The disadvantage is that
85+ the type gets more cumbersome. For instance, ` PState[User] ` would become ` PState[Future, User] ` .)
86+
5987{% assign prevTitle = "schema creation" %}
6088{% assign prevLink = "schema-creation.html" %}
6189{% assign upTitle = "the repository" %}
0 commit comments