Тёмный

Domain Modeling Made Functional - Scott Wlaschin - KanDDDinsky 2019 

KanDDDinsky
Подписаться 3,5 тыс.
Просмотров 52 тыс.
50% 1

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.

Опубликовано:

 

15 июн 2024

Поделиться:

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист
Посмотреть позже
Комментарии : 39   
@joshuas699
@joshuas699 Год назад
If I could force any programmer in the world to watch just one lecture, this lecture would be my choice.
@AlexTurpin
@AlexTurpin 13 дней назад
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.
@greyblake
@greyblake 3 года назад
One of the best talks about FP I ever watched.
@luizhenriqueamaralcosta629
@luizhenriqueamaralcosta629 3 месяца назад
Amazing Ideas in a clear and simple presentation. Thank you all.
@JPJeppe
@JPJeppe 3 года назад
Simple and powerful concepts!
@giorgos-4515
@giorgos-4515 5 месяцев назад
im writing a thesis on automating development, and everything there is object oriented, glad to see something fresh
@huslerbling
@huslerbling 2 года назад
Great talk and awesome book
@sergradzishevsky
@sergradzishevsky 2 года назад
great speaker, enjoyed the explanation
@scoop20906
@scoop20906 4 года назад
Interesting presentation.
@pr0master
@pr0master 3 года назад
Amazing, really Amazing
@fishzebra
@fishzebra 3 года назад
Brilliant, just need to convince my team
@curiosdevcookie
@curiosdevcookie 3 года назад
EEEhm, may I ask how that went at all?
@fishzebra
@fishzebra 3 года назад
@@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
@clown7094 3 года назад
Probably the hardest part ... 😅
@zyairekarson3334
@zyairekarson3334 2 года назад
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
@zyairekarson3334 2 года назад
@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
@huigangZhang 8 месяцев назад
Great talk, I wonder how easy to implement it using typescript instead of F#
@WilliamCWayne
@WilliamCWayne 2 года назад
Well, that's one book sold
@bocckoka
@bocckoka 4 года назад
oh... hey Scott
@djgreyjoy1495
@djgreyjoy1495 6 месяцев назад
Amazing talk! However it does not seem to support reading verified emails from the database ;)
@Eagle3302PL
@Eagle3302PL 10 месяцев назад
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
@heimeshoff 10 месяцев назад
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 RU-vid audience, but is part of the common knowledge at a DDD conference like KanDDDinsky.
@user-ux1mj1uz5b
@user-ux1mj1uz5b 3 года назад
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
@f0ggynights714 3 года назад
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
@reidosreis4k 6 месяцев назад
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
@Infinitesap
@Infinitesap Месяц назад
Regarding unittest (ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-2JB1_e5wZmU.html) I think a unittest is necessary to ensure the logic is correct?
@TJ-hs1qm
@TJ-hs1qm 6 месяцев назад
6:03 APL: hold my beer🙂
@sohamjoshi9527
@sohamjoshi9527 3 года назад
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
@atg1203 2 года назад
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
@sohamjoshi9527 2 года назад
@@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
@atg1203 2 года назад
@@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
@sohamjoshi9527 2 года назад
@@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
@rumble1925 8 месяцев назад
@@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
@very_uniq_handle 8 месяцев назад
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
@dipendrasingh352 6 месяцев назад
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.
@JDogB-tc3lx
@JDogB-tc3lx 9 дней назад
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???
Далее
Domain Modeling Made Functional - Scott Wlaschin
49:02
Просмотров 1,5 тыс.
Продаю тачку из гаража мечты :(
52:18
Functional programming design patterns by Scott Wlaschin
1:05:44
Domain Driven Design: What You Need To Know
8:42
Просмотров 95 тыс.
Scott Wlaschin - Railway oriented programming
56:55
Просмотров 11 тыс.
What is DDD - Eric Evans - DDD Europe 2019
57:06
Просмотров 253 тыс.