Susan Harkins (247) [Avatar] Offline
Please post errors in the published version of Functional and Reactive Domain Modeling here. We'll publish a comprehensive list for everyone's convenience. Thank you!

Susan Harkins
Errata Editor
Norbert Scheller (2) [Avatar] Offline
In chapter 3 and 4 you mention that scala.util.Try is a monad.
In fact Try is not a monad. It fails the left identity law.
But, the left identity law is not relevant in for-comprehensions.
So one can use Try safely in for-comprehensions.

Maybe one has to point out that Try is not a monad, but has a monadic API.
Debasish Ghosh (113) [Avatar] Offline
I mention as a footnote in Page 78 (Chapter 3) that Try violates a law of being a monad. I also provide a link to the SIP which discusses the details.

Norbert Scheller (2) [Avatar] Offline
Sorry, my fault!! I missed that!!
I love your book!!
Martijn Blankestijn (1) [Avatar] Offline
p. 123 the Applicative for List

I think the List should occur in first position as defined by the Applicative Trait.
override def ap[A, B](as: List[A])(fs: List[A => B]) =
for {
a <- as
f <- fs
} yield f(a)

Or did I miss anything?
Debasish Ghosh (113) [Avatar] Offline
Good catch .. you are absolutely correct! The arguments need to be flipped ..

Susan Harkins (247) [Avatar] Offline
339603 (2) [Avatar] Offline
Section 1.5, pg 30, verification of correctness code snippet, top of page:

Remove "=>" at the beginning of 4 lines, then this code will execute. Otherwise it's misleading.


val a = Account("a1', "John")

credit(a, 100).flatMap ...
=> Success(a.copy(balance ...
=> debit(Account("a1", ...
=> Success(a.copy(balance ...
=> Success(Account("a1", ...
339603 (2) [Avatar] Offline
pg 29, Listing 1.10 end, top of page

object AccountService extends AccountService

The above object declaration should be outside of the closing brace for trait AccountService.
In other words, the object declaration should be below the closing brace that appears on the next line, rather than above it.

pschwarz (8) [Avatar] Offline
'Exceptions in Scala' sidebar (in 1.3.1) references generateAuditLog in listing 1.6, but the listing does not contain generateAuditLog
Susan Harkins (247) [Avatar] Offline
Phil Derome (33) [Avatar] Offline
Section 6.4.1 discussing Akka Streams in context.

The description of Sink seems to copy too much from Source description: Sink says "In, to be written into" but should say "to be read from" or something equivalent.
Phil Derome (33) [Avatar] Offline
Section 6.4.1 A sample use case (AkkaStreams)
Step 4: Run the Computation
code should be simply "". Adding a foreach(println) prints a superfluous "Done" from Akka.Done. The transactions are already printed from the txnSink.

I may potentially volunteer to make a PR on code sample to make quite a few of the objects Main actually runnable so that we can see better immediately run-time behaviour (for instance this step 4 code here was commented out because the code Object is just a Scala Object, not one to be run directly from JVM lacking a main entry point).
Debasish Ghosh (113) [Avatar] Offline
Regarding the definition of source and sink .. I don't think there is any error in the description ..

It specifies :

A Source[+Out, +Mat] takes data from input and has a single output, Out to be written into.

So source is something that takes data from input, which is correct.

A Sink[+In, +Mat] has a single input, In, to be written into.

which is also correct.
Debasish Ghosh (113) [Avatar] Offline
Regarding the println, I do appreciate the fact that a redundant print is produced. But that does not affect the main topic of discussion. But I will appreciate a PR and will merge it if it does not have any conflicting change with the main text.