A Scala version of https://github.com/swlaschin/DomainModelingMadeFunctional
Some more flavors will come. Plan is to use idiomatic Scala version as opposed to F# in Scala.
Next thing to come is to use ZLayer instead of curried functions DI.
JSON won't be implemented.
Scala requires more of them than F#. It has pros and cons.
I, as a programmer, had problem with inferring type OrderQuantity.create productCode parameter and is other places.
Parameter name is usually enough for me.
Another value I see in type ascriptions is that F# requires more comments.
Another difference is that F# uses let and that's it.
In Scala I need two things: val and def. The second one usually when I need type params.
I use it in most places here, I don't like it. Scala is not Haskell nor F#. Which one looks better for non-programmer? I don't know. I don't know any non-programmer :-)
I added Result like in F# original version, however I kept error on left side.
I didn't add AsyncResult - too much hassle. I'm using IO from ZIO.
Somehow I couldn't make type aliases to be visible everywhere (however I didn't try hard), that's a pity.
At some point I'll try to rewrite with opaque types and sum types...
Philip Schwarz got it covered!
I kept files almost like in F# original. Awkward in Scala I think. I merged SimpleTypes and CompoundTypes in package object.
I don't think it's a code that domain expert would event try to comprehend. However for me it's much better than what I usually produce.
It's subjective but I like it more than naive translation.
I removed many types definitions and I use them inline. It's easier to me to read exact type than trying to remember if this dependency was A => B or WrappedA => Result[Err, B] or A => IO[Err, B].
What is nice about F# is that it requires so few constructs: one let vs def and val for example.
I don't like curried application with parentheses in Scala. I prefer parameters lists.