Agree that factory methods have their use but I propose it is to define behaviour and therefore should reflect the domain behaviour , ie instead of create from shopping cart which you must admit was obvious in the constructor too, instead LoadFromExistingCart may be better. Whilst code intent is ok, most devs can read code and glean intent, but domain language translates business behaviour which is often obfuscated by technical languages.
Wow. I don't know how you got here, but I totallt appreciate. I think some of the topics I cover on this channel are also applicable to Java as well. Thanks again.
Dan, Excellent and well-presented tutorial. Factory methods are also a must for Inversion of Control. OneOf is new to me. I have been throwing custom exceptions in my domain model factory methods. OneOf is cleaner and I believe a better way to manage validation exceptions. Will use it in future development. Great stuff, please continue lecturing, and thanks for all your knowledge-sharing.
Many thanks for your thought on this. I have showed OneOff because I think it's something worth taking into consideration. Yet I'm not sure if I want to use it in a customer app or not. I think it would be great when discriminated unions will come to C#, but nobody knows exactly when that will happen.
I also prefer this approach. Btw, I have a video only on the idea of rich domain model. Plus the entire DDD FUndamentals playlist. Let me know what youthink about those videos.
I love your videos so much and thank you very much. I love static factory, but I do not like OneOf library - as there is another better library that is simple such as Optional
Its really a good thought of using factory methods over constructors. But dont you feel the heavy usage of factory methods leads to OCP(Open closed principle) Violation. We need to rethink again on the usage of the factories.
Here I tend to disagree. I guess I have talked about this in different videos, but in my opinion it's wrong to add everything to the DI conainer just because we can. When it comes to validation in real apps we have multipe validations scopes/contextx. Client side validation, API contract validation, application level validation, domain model validation. Of course, we could use the Fluent validation library for all different types of validation. Also in real applications you'd probably validate different classes at each stage. Like ProductContract for API contract validation, a ProductDto for application level validation and a Product for domain model validation. I know this became a little bit long but I would strongly recommend against adding the domain model validators to the DI container. The domain should be self-contained, self-sufficient and it shouldn't depend on other parts of the application (like a DI container).
The only problem I have with static factory method is you can't mock them. So if someone breaks one it'll cause other tests to potentially fail. As opposed to a factory through DI that I can inject and then mock methods. Unless I'm missing something :)
I'm not sure I want to enter this discussion because it's usually very opinionated :)). But the way I see things, you can definitely unit test the factory methods without the need to mock anything. That proves that your factories are doing the job. If the static method doesn't interact with external dependencies and it doesn't hold state, unit tests are easy. So, why would you want to mock them? If you already know that your factories are working, you can just use them to create your objects within the test. In practice I never felt the need to really mock them. If you static methods depende on external dependencies or hold state and you want to unit test it, you can create wrapper classes around them that you add to the DI when you're testing.
@@Codewrinkles totally understand the desire to avoid potentially opinated sections. Guess my worry is a developer changing the code in a factory that causes incidental failures. But that's probably me being more of a worry wort then anything. Thank you!
No, I'm glad you brought this up. And in fact I'm still thinking about this. Maybe I'm just missing a practical use cases. But in my experience till now, factory methods are usually used on domain models. For everything else you rely on DI. Now, for the domain models, you can easily unit test the factories. If somebody changes something in a factory that breaks things, it would be caught by the unit tests.
I would suggest that finding out someone broke a factory method is a good thing, that afterall is why we write tests. Ok it may not be the specific reason for that given test but it is still a test. I don't see the concern. Mocking is generally used to remove external resources like file systems, clocks, databases, etc. Not other code generally speaking.
But we can use comment, Constructors do not have to express the intent of the code. i mean that can't be a valid reason to use factory method over constructor, beside the point that it would depends on other factors as well.
Agree that factory methods have their use but I propose it is to define behaviour and therefore should reflect the domain behaviour , ie instead of create from shopping cart which you must admit was obvious in the constructor too, instead LoadFromExistingCart may be better. Whilst code intent is ok, most devs can read code and glean intent, but domain language translates business behaviour which is often obfuscated by technical languages.
I fully agree.
looks like Rust 'match' and Option and Result
Could be. I have never tries out Rust, although I see it's popular and therefore also with the appropriate amount of drama with the Rust Foundation.
Because of this video, I will always use factory methods
I'm a java dev, but this is the only C# channel I always watch
Wow. I don't know how you got here, but I totallt appreciate. I think some of the topics I cover on this channel are also applicable to Java as well. Thanks again.
Your explanations are so clear and to the point! Thanks!
Glad you like them!
I love factory methods. I use them very often
Yep, me too!
Dan, Excellent and well-presented tutorial. Factory methods are also a must for Inversion of Control. OneOf is new to me. I have been throwing custom exceptions in my domain model factory methods. OneOf is cleaner and I believe a better way to manage validation exceptions. Will use it in future development. Great stuff, please continue lecturing, and thanks for all your knowledge-sharing.
Many thanks for your thought on this. I have showed OneOff because I think it's something worth taking into consideration. Yet I'm not sure if I want to use it in a customer app or not. I think it would be great when discriminated unions will come to C#, but nobody knows exactly when that will happen.
Great video! I fully agree with your 2 points on using static factory methods.
Thanks!
Glad you enjoyed it! And thanks for stopping by and commenting.
Especially in rich domain models, e.g. when one applies DDD, I prefer the approach you showed here.
I also prefer this approach. Btw, I have a video only on the idea of rich domain model. Plus the entire DDD FUndamentals playlist. Let me know what youthink about those videos.
earned a subscriber, good work
Thank you! Hope you'll also enjoy the other videos on the channel.
It's a very interesting approach. Always learning new stuff from you, I'll be using that now :)
Glad you found it interesting.
Hum!! Nice, very Interesting and useful as always. Thank you.
Also in a factory method you can await for things! Love your videos!
True. I forot to mention that. Thank you for your addition. And for the feedback ofc :)
Great video Dan, thanks! Got loads of ideas for improvement! 😀
Great to hear!
Thank you for the great information.
Glad it was helpful!
I love your videos so much and thank you very much. I love static factory, but I do not like OneOf library - as there is another better library that is simple such as Optional
Thanks for sharing!
Its really a good thought of using factory methods over constructors. But dont you feel the heavy usage of factory methods leads to OCP(Open closed principle) Violation. We need to rethink again on the usage of the factories.
Can you please expand on this? How are factory methods violating OCP?
Thinking about this, I feel more like factory methods enforce OCP than violate it.
Thanks for the video. Does it still relevant for the real world when there is DI with all its nice features in place?
It's of course still relevant as you don't have all your classes in DI and most probably you don't have your models added to the DI container.
@@Codewrinkles The FluentValidation normally is in the DI container, so is there a problem to depend on the Validator inside the model class?
Here I tend to disagree. I guess I have talked about this in different videos, but in my opinion it's wrong to add everything to the DI conainer just because we can. When it comes to validation in real apps we have multipe validations scopes/contextx. Client side validation, API contract validation, application level validation, domain model validation. Of course, we could use the Fluent validation library for all different types of validation. Also in real applications you'd probably validate different classes at each stage. Like ProductContract for API contract validation, a ProductDto for application level validation and a Product for domain model validation. I know this became a little bit long but I would strongly recommend against adding the domain model validators to the DI container. The domain should be self-contained, self-sufficient and it shouldn't depend on other parts of the application (like a DI container).
@@Codewrinkles I see, thank u for share your knowledge
The only problem I have with static factory method is you can't mock them. So if someone breaks one it'll cause other tests to potentially fail. As opposed to a factory through DI that I can inject and then mock methods. Unless I'm missing something :)
I'm not sure I want to enter this discussion because it's usually very opinionated :)).
But the way I see things, you can definitely unit test the factory methods without the need to mock anything. That proves that your factories are doing the job. If the static method doesn't interact with external dependencies and it doesn't hold state, unit tests are easy.
So, why would you want to mock them? If you already know that your factories are working, you can just use them to create your objects within the test. In practice I never felt the need to really mock them.
If you static methods depende on external dependencies or hold state and you want to unit test it, you can create wrapper classes around them that you add to the DI when you're testing.
@@Codewrinkles totally understand the desire to avoid potentially opinated sections. Guess my worry is a developer changing the code in a factory that causes incidental failures. But that's probably me being more of a worry wort then anything.
Thank you!
No, I'm glad you brought this up. And in fact I'm still thinking about this. Maybe I'm just missing a practical use cases. But in my experience till now, factory methods are usually used on domain models. For everything else you rely on DI. Now, for the domain models, you can easily unit test the factories. If somebody changes something in a factory that breaks things, it would be caught by the unit tests.
I would suggest that finding out someone broke a factory method is a good thing, that afterall is why we write tests. Ok it may not be the specific reason for that given test but it is still a test. I don't see the concern. Mocking is generally used to remove external resources like file systems, clocks, databases, etc. Not other code generally speaking.
@@allannielsen4752 Interesting, perhaps I have been over mocking my tests. 🤔
But we can use comment, Constructors do not have to express the intent of the code. i mean that can't be a valid reason to use factory method over constructor, beside the point that it would depends on other factors as well.