DEV Community

loading...

Discussion on: Domain modeling obsession

Collapse
tarodbofh profile image
Juan Ara

The thing about sum | choice types is that the state machine around the status (in your example) is hard to design to allow parallel processing, i.e. when it's purely a linear flow, it's easy to model but when the domain grows and there are collaborators that alter part of the order either (pun intended) you need to redesign (which is not bad, after all needs and infra changed) or be extremely careful about where and how coupling happens.

Collapse
tarodbofh profile image
Juan Ara

BTW, the Validated approach, though nice, hides for me a fear for null. Since you are using kotlin, a validateEmail(email: String) would just return a ValidatedEmail (inline) or null.
Embrace null! Null is a valid domain idea! Check github.com/Kotlin/KEEP/blob/master...
At that link there are a lot of references about idiomatic kotlin being direct style instead of railway style (though doesn't forbid the 2nd!):

However, core Kotlin language and its Standard Library are designed around a direct programming style in mind.
Collapse
eureka84 profile image
Angelo Sciarra Author

I really like Kotlin nullable types because they force you to think about nullability and provides compile time checks against nullability.
I would use them maybe instead of data types like Option, because, as you said they are more idiomatic. I wouldn't go and use them in place of Eithers or Validated because they are currying other kinds of information and not simply the presence/absence of a value.

Collapse
eureka84 profile image
Angelo Sciarra Author

Well I have seen how difficult it is to work with a model that is in a 1:1 relation with its DB representation and I would say I would take my chances with choice types...