Domain Modeling Made Functional - Scott Wlaschin
ฝัง
- เผยแพร่เมื่อ 16 ต.ค. 2024
- 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.
NDC Conferences
ndcoslo.com
ndcconferences...
Best argument I've seen for using a functional approach for line-of-business projects. Most developers think of FP as a specialised technique for scientific or mathematical programming. This presentation blows that out of the water.
Pity there's such a small audience for these ideas.
Functional programming is actually becoming big in the frontend/web world! React and Vue, the two most popular frameworks, are both based on functional programming concepts, and Immutable.js is quite popular too. I think many frontend developers would be ready to switch to a typed pure functional language, to get the guarantees that they offer.
@@h3rteby the problem with react and vue is that while they are based on immutability and functional reactive stuff, they Do not have the type-System benefits. A Good type System is imo at least half the value of FP. Bucklescript/REASONML are most likely the things that could make it more popular, altough i strongly dislike reasons Syntax, and some of their compromises make it Hard to recommend for doubtful people (separate Operator for floating point Arithmetic for example).
Elm and purescript are where it's at, but purescript can be very complex very Quickly because its based on the math heavy type System of haskell, while Elm can *feel* very limiting, as it requires an immense Shift in how you See pretty much everything in your code
@@leonk6950 True, they're a stepping stone though. When you know React/Redux/Immutablejs, then Elm doesn't look so alien anymore. I've actually been using Elm in production for over a year now :)
@@h3rteby I call them "gateway" languages, as I started learning React, I figured that Redux was good to manage the state, then learned Elm and ended with Haskell (so far).
I had studied Miranda in university, in early 2000s. I was marveled at map, filter, fold, and at the theory behind, but the Haskell ecosystem was nowhere near as good as it is today. However, it made enough impact in myself to make me feel bad since, as typing loops and having to use Java again (java generics just had come out and were not widespread) looked so archaic and low-level...
I think the audience is a lot larger than you realize
Wow. This is great stuff; I'll be watching this more than once. In fact, I just bought his book.
These days every new "innovation" that any object-oriented language rolls out is actually something functional programming has been doing for years. That's object-oriented language designers confessing to us all that functional programming really is the better way forward.
So why not stop with the OOP bandaids and just go ahead and embrace FP?
To be honest f# has been taking stuff from c# for a while now, it's not oop only taking stuff from functional especially when it comes to performance.
@@FilipCordas What features do you have in mind? Specifically, what OOP features do you have in mind that have been ported to F# after coming into C#?
@@januszwrobel Janusz Wróbel Well I am thinking about all the new stuff that comes with Roslyn. Struct refs Spans...
@@FilipCordas That's all good, but not sure it has anything to do with OOP specifically. it could as well be considered a feature of F# as of C# - it's a .NET feature. You might see a lot more blogs advertising these features in the context of C#, but that's simply because C# is more popular.
I somewhat agree with you in the sense that not all the innovation is taken from old functional concepts - some are new addons to .NET CLR. They are not OOP concepts though.
@@januszwrobel This is why F# will never be used on large scale people that use it care more about if something is oop than the underlying thing. Yes Spans refs are OOP because they are just a workaround to make classes more performant you don't need them in procedural programming. They are just a product of Roslyn being written in c#. I think that when it comes to performance functional languages do have a problem because it's not that you can't write performant code it's just that you need to think about it way too much.
It's always a relief to find your talks. Most speakers on these topics are PR time wasters, sent on a day trip from the office, meme slides, surface level devs, or being funny. Thank you.
another top talk from Scott. Absolute clarity. Functional demystified and concrete understandable examples. Recommend his book. I've used Java for 20 years or more and wondered why I've always had an awkward love-hate relationship with it. This is another aha moment.
This talk changed how I write code
Great stuff, shows how f#’s design fits in so nicely with DDD - really useful thanks
I'm blown away with this talk. I bought the book from Scott and hope to help me think more about Domain Modeling
Excellent talk, especially after that previous one earlier in the day. The intimidation factor of F# has been slashed completely. Now to somehow work out how to integrate f# gradually into the c# company I work for...
You know he has a series about that topic on his blog.
Thank you very much! How beautiful Functional Programming is! I wish I had begun my programming journey as a functional programmer rather than starting with OOP.
Loved this presentation, one question though: in the final example where ContactInfo can be one of 3 choices, does that mean any caller that wants to use ContactInfo must now be able to handle all 3 types (I'm especially curious about the "pair" type EmailAndAddr), or is there some magic in functional languages that makes this easy? I'm more used to OO so it felt like this was one of the areas where a shared interface / encapsulated behaviour sounds nice.
You'd have to pattern match the new cases, however, FP does have a trick to reduce the amount of code you have to write which is composition. The code which actually does something with some contact info will not be in the same function that's doing the pattern matching, so really all you have to do is some light plumbing (in the form of pattern matching, deconstructing and function application).
Ths pair type would simply be like a tuple deconstruction instead of a single value.
There is a duality between data and behaviour, by making it easier to extend one, you make it harder to extend the other.
I wish some F# features to be added to C#. Like declaring new types out of existing types, or the let keyword to ensure immutability of sub expressions. This seems feasible...
In C# instead of let you may write a const keyword when you're declaring a local variable
I like the more relatable names at 7:08.
This is so helpful - even though I don't use a functional programming language.
Great video :). I like to see future videos with real projects for example simple blog tutorial. How to code reuse without inheritance, how the code be open for extension. In OOP you inject interface. Here i have pattern matching but all the cases are in the function. if i add new type i should change the function itself. If i have 20 types the function becomes very large. With real project like blog things and fp patterns will be more understandable.
Hi, you can check out his site at fsharpforfunandprofit.com
I'm about halfway through the talk. Very interesting so far. I can see how this would be useful for starting a new project. But can functional DDD be of use to an existing non-functional project? Could functional DDD be used to reason about and/or validate a complex project written in C#, for example? Could I either generate a function type spec from the exist class design, or could I create functional type spec from my mental model of the system and validate it against the actual code?
Scott - You are awesome. I am in lov with your presentation :) superb !!!
I am unfortunately bounded to Python and C++, however I am gonna try my best matching this approach in Python and C++ and pass this message whoever I talk to that writes codes. Thank you.
So where does the business logic live? separate powerpoint slides? can someone explain the filesystem or namespaces or something in f#
Blew my mind.
The "Product" equivalency is sometimes made explicit for no reason e.g. Microsoft's use of the term "SKU".
works great with typescript :)
Not really. Null.
Great talk as always!
Great talk, ive learned a lot of stuff!!!
Great presentation and content...
Great, very informative talk!
Such a great video
Excellent talk !
19:31 "Glue things together like lego" 🤔
You've been doing legos wrong if you didn't glue them.
Mr. Business?
Excellent
I wouldn't compare union types with interface implementation. They're more like enums (from the points raised here at least).
no. these are a fixed set of "sealed" interface or abstract class imlementations and can have different field sets. enum is the fixed set of singleton instances of the same type.
yeah but enums can't have their own data like unions
The point of algebraic data types is to having sum type and product type at the same time. So that you can modeling kind of domain type without stretching. Say you have a type is Payment, and Payment could be CreditCard(no: Long, cvv: Int) or Cash(amount: Double) or just FreeCoupon(id: UUID). In so these three kinds of payments are all under same interface/type so that use can accept them in a function parameter, and handle them case by case like a switch statement. In exchange, you don't have to force them to expose same properties(which is unnatural and stretching), and eventually makes your code simple and straightforward.
18:50 The 'functional design of CardGame' has almost exactly the same flaws as the slide with object oriented Contract from earlier?? Horseraddish, I say
He's the real hero.
"| types" look like sealed classes in Kotlin and "* types" as data classes
There's only one difficulty I see with the Single Variant type and avoiding invalid state by design: initial state.
If you provide the user with a fresh modal in which he can enter a customer, the fields `email`, `firstName` etc. are *supposed* to be empty. This is an unwanted state when saving the user later but it is a *wanted* initial UI state.
Both domains, UI and business logic, overlap at that point and produce a problem.
Can someone help me on that?
Help is very much appreaciated!
You probably don't want use same type for representing both UI and domain state. For UI you probably needs an Optional for email under Profile type, so that you can represent it in the first place and then let user type it. Then you can validate this type and return an Either, and Profile has a non-empty Email field there.
@@yifanwang4906 Ha! That was exactly what I came up with after days of thinking!! :D
@@yifanwang4906this is definitely not correct. In this kind of situation you would want to differentiate between your state management states and your local UI state.
If it's a form or some kind of user input, you would have a local UI state that contains the state locally being modified. Your state management would have something like "initialState and setState" with only setState containing your model. You then pattern match on these states in the UI and the UI decides it's initial state if the state is initialState.
Basically you need to separate the idea of a domain model from the state of the application as well as separate this from the UI state. This becomes especially obvious when you try to get information from the backend and are forced to have "loading, success, failure" states that clearly have nothing to do with your domain model. It's the same thing with initialstate and setstate
35:44 Why not to throw an exception? Why anything invalid reflects to valid "nothing"? Is "nothing" a valid value for EmailAddress? why?
I would say that this is "createEmailAddress" and not "validateEmailAddress”. You will most likely validate the email at some other place. Especially, since a missing email is not a very exceptional situation - we expect that something like that will happen.
If you validated it in another place what is the point to validate it here? Just put that validated result, no need for additional check, right? I know it's not right, that is called information lose. If you do A=B/C you expect DivideByZeroException in case of C was 0. Otherwise blue screen/money lose/rocket out of the orbit/other unpredictable things will happen. Here is exactly that situation, exception should be thrown if developer who called this code passed wrong argument.
In DDD all the logic should be within the domain. This allows the code to be written in a way that it doesn't care if you're using it on the web or a desktop GUI. It doesn't care if you store it in a RDMS or NoSQL.
So? How does DDD prevent us from using exceptions?
You could introduce a different return type. For example: Either where the method explicitly tells you that it can either return an Email instance or, for example, an Error instance. Note that Error is NOT an exception. Exceptions should be for really excepitional cases, cases that you are not prepared nor know how to handle. An incorrectly formated email is not such a case.
The yellow foot phenomenologically delay because lake gully tour toward a divergent farm. polite, free fish