Domain Modeling Made Functional - Scott Wlaschin - KanDDDinsky 2019

Statically typed functional programming languages encourage a very different way of thinking about types. The type system is your friend, not an annoyance, and can be used in many ways that might not be familiar to OO programmers. Types can be used to represent the domain in a fine-grained, self documenting way. And in many cases, types can even be used to encode business rules so that you literally cannot create incorrect code. You can then use the static type checking almost as an instant unit test - making sure that your code is correct at compile time. In this talk, we'll look at some of the ways you can use types as part of a domain driven design process, with some simple real world examples in F#. No jargon, no maths, and no prior F# experience necessary.

[@joshuas699]

If I could force any programmer in the world to watch just one lecture, this lecture would be my choice.

[@greyblake]

One of the best talks about FP I ever watched.

[@pr0master]

Amazing, really Amazing

[@JPJeppe]

Simple and powerful concepts!

[@huslerbling]

Great talk and awesome book

[@scoop20906]

Interesting presentation.

[@sergradzishevsky]

great speaker, enjoyed the explanation

[@giorgos-4515]

im writing a thesis on automating development, and everything there is object oriented, glad to see something fresh

[@luizhenriqueamaralcosta629]

Amazing Ideas in a clear and simple presentation. Thank you all.

[@fishzebra]

Brilliant, just need to convince my team

[@curiosdevcookie]

EEEhm, may I ask how that went at all?

[@fishzebra]

@@curiosdevcookie There was no interest to be honest, I couldn't get them past the usual barrier of looking at F# to even look at the DDD type design idea. I guess they are busy and love C# too much. But next time I prototype a domain I shall use F# and not tell them what it is at first. Luckily C# Record Types are a lot closer to Product Types and it should be easy to translate the planning work.

[@clown7094]

Probably the hardest part ... 😅

[@zyairekarson3334]

i guess Im randomly asking but does anybody know of a method to get back into an instagram account..? I was stupid lost the login password. I appreciate any help you can offer me!

[@zyairekarson3334]

@Flynn Andres Thanks for your reply. I got to the site thru google and I'm trying it out now. Looks like it's gonna take quite some time so I will reply here later when my account password hopefully is recovered.

[@huigangZhang]

Great talk, I wonder how easy to implement it using typescript instead of F#

[@WilliamCWayne]

Well, that's one book sold

[@bocckoka]

oh... hey Scott

[@djgreyjoy1495]

Amazing talk! However it does not seem to support reading verified emails from the database ;)

[@Eagle3302PL]

Ok, but I can't just send Email | VerifiedEmail to the DB or to the FE, they need the flag to be able to distinguish. So my options are to convert my model to FEModel -> BEModel -> DBModel on every transaction, or I just keep a flag and put in a single if statement in my code. I'm struggling to see how this helps us build APIs specifically for CRUD, there is actually more boilerplate here, it's just sitting in Types rather than Services. All my conditionals will still have to occur in whatever API interface is responsible for receiving and sending data to the client, so why not just have them in the service and let exceptions propagate? I guess you can claim that now all these conditions are in the model, but in OOP I can have my conditions in the model too, just put the rules into setters.

[@heimeshoff]

Oh that is definetly true. Your arguments/examples are optimising for a different scenario than Scott's. In a CRUD world with simple domain rules and a handful of if/then/else statements, I'd say you might be better off with a simple DB and some OR-Mapper or simple object model. The benefint you get from Scott's talk arises in complex domain models. When the difficulty of development lies in linguistic nuances and context specific behaviors that will never be stable but constantly evolve with your learning about the domain. Then you want a domain model that can never be in an illegal state and where everything is semantic and typesafe. That has not been made explicit enough in the talk for a later KZbin audience, but is part of the common knowledge at a DDD conference like KanDDDinsky.

[@user-ux1mj1uz5b]

Hi, thank you for this content. I have a question. In about 36:50 in the video, the Option function is returning None. Which means the if the user of that function needs to return an error message, he has to read the implementation code, analyze it, then return the correct message... What is the best way (or what are the best options available) for returning error messages in functional programming? Thanks

[@f0ggynights714]

You could define the error message directly in the implementation of the createOrderLineQty function. In order to return that you would use a different type than Option, for example the build in Result-Type wich is exactly made for such cases where you either want to return a valid result or some error information. You can of course also just define a custom sum-type that fits your specific needs.

[@reidosreis4k]

Late answer, I know. But functional progamming has an Either / Result type, which lets you return either your successful result, or a failure result. So if you wanted to parse a string to an int, you could have a return type of Either, with the string being the error message, and the int being the successfully parsed int

[@TJ-hs1qm]

6:03 APL: hold my beer🙂

[@sohamjoshi9527]

this is just showing off the F# static type system to enforce trivial constraints... where are the actual business rules and how they can be modeled using functions ?

[@atg1203]

I think what he's getting at is that the "types" represent the domain object and the business rules are enforced in the function "constructor" when you're creating the type.

[@sohamjoshi9527]

@@atg1203 But business logic in DDD is so much more, its what happens in-between/interaction among the objects in OO style. Now ofcourse with the type system he has been able to apply a few compile time constraints on what the variable can hold, but I dont think its possible to model domain rules using this methodology.. I need to dig deeper into F# functional world to see a parallel for the OO style of implementing domain logic using object interaction.

[@atg1203]

@@sohamjoshi9527 well yes, the idea is that all of those get modeled in standalone "services" which themselves are composed using pure functions. So you do away with "classes" and methods but have these Types which represent your entities and then service(s) which act on variables of these Types. I'm using Typescript to to DDD using FP (as far as possible)

[@sohamjoshi9527]

@@atg1203 That makes sense. Thanks for the pointers, will be delving more into this. Yea typescript is nice and has these union types etc also.

[@rumble1925]

@@sohamjoshi9527google “Full-stack ReScript. Architecture Overview” Its not f# but it gives you a very good outline of how to structure types and actions on those types

[@very_uniq_handle]

It looks nice in the ideal world, until one day when the business rules change but all the hard coded types have been widely spread everywhere in your codebase, even in the codebases owned by downstream systems. Then you need to refactor a large portion of the code and convince other downstream teams for migration, which could be painful as I can imagine.

[@dipendrasingh352]

You can create an architectural boundary for this. You can read up on Clean Architecture or Hexagonal Architecture. Domain model never leaves your service & you just have to make sure to not allow other services to depend on your domain model. To add: Other services have their own domain model on which they depend independent from your own.