Great talk! Algebraic data types really are powerful, but it would've been nice to show how to reconciliate between the domain layer (where all the typing rules are enforced) and presentation layer (where one must parse commands in a wire protocol that is different from F# type system).
I wish I had this talk back when I was first trying to figure out why people liked functional programming so much. "It's all just data and functions" didn't sound that helpful without algebraic data types, and those sounded too scary to try and understand before coming around full circle with TypeScript discriminated unions and now exploring languages like ReScript and Gleam. Great talk Scott, my next FP exploration is how IO fits in all this and I see you have another one on that that I will be watching next.
@@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.
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!
@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.
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.
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 UA-cam audience, but is part of the common knowledge at a DDD conference like KanDDDinsky.
46:53 I don’t think this would scale, if more contact infos are added. I think a collection makes more sense, and it would have to have at least one item. But how do you describe that constraint in code? Typescript can give you a length value at compile time, but only for a fixed-length array.
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
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.
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
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 ?
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.
@@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.
@@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)
@@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
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.
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.
what the hell? dude you can easily make a function in c# or java that takes a type of whatever (fruit in this example). you make an enum called fruit, put your types of fruit in the enum, then pass that into the argument of the function. bro do you even code???
Enums are algebraic data types my dude. Also can you do `Card = Suit * Rank` in Java? Or do you have to write a bunch of boilerplate to make that happen? Dude in the video actually said it's possible in other languages, but people are less likely to do it if it's not a language feature. Just like people are way more likely to create mutable fields or inheritable classes when that is the default
If I could force any programmer in the world to watch just one lecture, this lecture would be my choice.
im writing a thesis on automating development, and everything there is object oriented, glad to see something fresh
One of the best talks about FP I ever watched.
Great talk! Algebraic data types really are powerful, but it would've been nice to show how to reconciliate between the domain layer (where all the typing rules are enforced) and presentation layer (where one must parse commands in a wire protocol that is different from F# type system).
Simple and powerful concepts!
Amazing Ideas in a clear and simple presentation. Thank you all.
I wish I had this talk back when I was first trying to figure out why people liked functional programming so much. "It's all just data and functions" didn't sound that helpful without algebraic data types, and those sounded too scary to try and understand before coming around full circle with TypeScript discriminated unions and now exploring languages like ReScript and Gleam. Great talk Scott, my next FP exploration is how IO fits in all this and I see you have another one on that that I will be watching next.
great speaker, enjoyed the explanation
Brilliant, just need to convince my team
EEEhm, may I ask how that went at all?
@@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.
Probably the hardest part ... 😅
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!
@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.
Interesting presentation.
Great talk and awesome book
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.
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 UA-cam audience, but is part of the common knowledge at a DDD conference like KanDDDinsky.
Great talk, I wonder how easy to implement it using typescript instead of F#
46:53 I don’t think this would scale, if more contact infos are added. I think a collection makes more sense, and it would have to have at least one item. But how do you describe that constraint in code? Typescript can give you a length value at compile time, but only for a fixed-length array.
Not possible, you'd have to express it as a pair
type NonEmptyList
Amazing talk! However it does not seem to support reading verified emails from the database ;)
Amazing, really Amazing
oh... hey Scott
Well, that's one book sold
6:03 APL: hold my beer🙂
Regarding unittest (ua-cam.com/video/2JB1_e5wZmU/v-deo.html) I think a unittest is necessary to ensure the logic is correct?
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
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.
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
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 ?
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.
@@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.
@@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)
@@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.
@@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
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.
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.
what the hell? dude you can easily make a function in c# or java that takes a type of whatever (fruit in this example). you make an enum called fruit, put your types of fruit in the enum, then pass that into the argument of the function. bro do you even code???
Enums are algebraic data types my dude. Also can you do `Card = Suit * Rank` in Java?
Or do you have to write a bunch of boilerplate to make that happen? Dude in the video actually said it's possible in other languages, but people are less likely to do it if it's not a language feature. Just like people are way more likely to create mutable fields or inheritable classes when that is the default