Make Domain Rules Explicit In Any Business Application

[@marklord7614]

I've yet to find another C# content provider who delivers quality content at this level. Even when you tune in to watch the main topic, you'll likely walk away with some other gem you didn't know you needed. We get this all for free, so I hope others join in and support Zoran's efforts here. Cheers all and happy coding.

[@oliver-münzberg]

4:50 This will cause that the given title " I started with a whitespace" will be changed to an empty string because if any rule fail all rules where applied to the given title

[@XXnickles]

I was looking for an abstraction like this for some validation scenarios. This is just beautiful code as usual! Thanks so much for tackling this scenario

[@Tesfamichael.G]

This is definitely one I'll be watching again. Nice video! Thank you Zoran!

[@julealgon]

This was a very fresh way to handle validation and suggestions. The use of the composite pattern to combine rules is super strong and the approach of defining different rules at different levels of the application (domain-level rules, API rules, etc) using the same abstraction is extremely elegant. I thought it was interesting how you didn't use the rule to sanitize the data, but to return as a suggestion instead so that the final value is always decided by the caller. At that point, it almost feels like an extended validation engine with suggestion support, which is a fairly cool concept in and of itself, and does make a ton of sense for a book entry system. I would love to see an attempt to integrate this abstraction with well-known libraries for validation such as Fluent Validation.

[@roll-outcommanders6520]

Another excellent video introducing the concept of Rules and Object Validation, Zoran. After your introduction, I would be looking for a package to provide the boiler plate for this delegation. This is due to the "flexibility" it gives developers to implement their own "style" when implementing the interface. There still remains an aspect of clean code that needs to be addressed in actual implementations IMHO.

[@ChrisWalshZX]

Another fantastic video Zoran. I wondered how a book title could be validated from last week's video. I knew from previous videos that it would involve making Book Title a record type of it's own and moving all validation out of Book and into the BookTitle create methods/constructor. But the rules pattern - what a great new example of functional style programming and nice use of Aggregate() too.

[@bphatness3924]

This is why Zoran is the GOAT!

[@nikolasavic5917]

Amazing video as always. Makes me think that each new problem can be solved with one or more additional classes, keeping each class short and only handling one responsibility. One thing I'm interested in is what are your preferences. where do you use composite and where do you use chain of responsibility pattern?

[@marcoshuck]

This is also known as value-objects in DDD, great video!

[@hemant-sathe]

Great video, cleared the difference between a rule and validation. In a software product, many rules are configurable, some come as data driven, some as logic driven. Also in the settings section, we need to select which rules apply for the running product. (example, settings in VS Code) also configuration using json. Are these covered already or if there is a plan to cover these at least at introductory level of not in depth? TIA.

[@sashbot9707]

First, and I want to thank you for all your insightfull videos.

[@nickbarton3191]

Nice separation of concerns. What Uncle Bob always says, the rules that are specific to the business and rules specific to external demands such as legislation, also should be separated.

[@bernardoherrera5217]

The best of the Best! Thanks for this video! Which Books would you recommend to wrap my head around this concepts?

[@zoran-horvat]

@@bernardoherrera5217 I keep with the fundamental books and university books, and then digest them my way when applying to concrete technologies. The greatest knowledge in books is between the lines...

[@KaineVarley]

Elegant and excellent!

[@okcharles7]

AllTitleValidity wears a handler clothes(ITitleValidity) but it is apparently a builder. It looks neat and clean but a little bit implicit at the same time. I would prefer chain of responsibility pattern to it, in which the building and calling responsibilities are explicitly separated.

[@zoran-horvat]

How is that a builder?

[@okcharles7]

@@zoran-horvathow would you trigger other validators to work in a call without it? It is registering validators giving order of execution

[@zoran-horvat]

@okcharles7 How do you know it is giving order of execution? It is an interface.

[@okcharles7]

@@zoran-horvat It is an implementation of the interface and its constructor accepts an array of other implementations. As long as I am concerned, IEnumerable.All and Aggregate iterate over all members of the array in the order of the index from zero. So, the order of execution of implementations is fixed by the arguments passed to the constructor. Even in case I am wrong, it is still true that the implementation has a power to coordinate execution of others including itself. For example, at 09:20, in line 24th, nothing can stop you from calling like this: new AllTitleValidity( new AllTitleValidity( new AllTitleValidty( // ... ))) or new AllTitleValidity( new AllTitleValidity(// ... ), new AllTitleValidty(// ...) )

[@zoran-horvat]

@okcharles7 Yes, and it will still work as expected. It is just an optimization to flatten-out the composite structure, but it doesn't change the functionality. However, "a power to coordinate execution" is a gross overstatement. That class doesn't organize anything. It's just a foreach loop.

[@kunetskiy]

It seems similar to Specification pattern. The only concern I have about that approach is how can I be sure that the value of BookTitle will stay valid after it has been validated? I mean why not to encapsulate such validation inside of the BookTitle class?

[@zoran-horvat]

@@kunetskiy You cannot incorporate domain validation I to a domain class because there can be several distinct sets of validity criteria for the same model.

[@rdoskoch]

Excellent 🎉

[@sandves]

What about async validations? Would you just make the interface return a task and execute them in parallell?

[@zoran-horvat]

@@sandves Ah, yes... Orthogonal concerns have the power to destroy even the most beautiful idea in programming. That aside, I think it would be beneficial to extend the rule interface with an async interface, so that all layers that do not concern asynchrony can continue behaving as before.

[@nanny07]

Another great video but with a catch: why register the Func into the DI? I think it should be a proper class because maybe it could be possible to search for claims in different places like httpcontext (the one you did) or databases or other APIs Registering the Func you will be force to have the same implementation every time you ask for a Func

[@zoran-horvat]

@@nanny07 That depends on the requirements.

[@Fikusiklol]

These are not domain rules. These are simple checks and could easily be done with FluentValidation or whatever. Domain rules are called domain for a reason and should belong there either as a straight up rule class or validation in domain services. This is just another class hidden behind abstraction that will fail to check for true invariants of a domain.

[@zoran-horvat]

@@Fikusiklol How is grammar and title capitalization not a domain rule in a book editing domain?

[@Fikusiklol]

​@@zoran-horvat Domain rules are checked in domain. These are checked in application. More than that, when it comes to true invariants, i.e checking some inner AR values or checking values across multiple AR's - then it will fail to do so. That's why this video might be confusing/misguiding when it comes to "hard" rules. Appreciate it nonetheless tho :)

[@zoran-horvat]

@Fikusiklol I think you are holding on to a very narrow and rigid definition of a domain, as something solely implemented in the domain tier. There is no logical explanation for such a constraint. I am not fond of practices like that.

[@Fikusiklol]

@@zoran-horvat Then why video is called domain rules, not just rules?

[@zoran-horvat]

@Fikusiklol The entire application implements the domain. Why is it called application, then? The logic goes the other way around. Domain model only models the domain, no cross-cutting concerns or anything. But that does not imply that the domain will not exist in the rest of the application. Why would it be so?

[@sotsch9280]

Great Video! But I would omit the "UserRoleTitleRule" because its up to the ApplicationLayer to prove for. I would only use Rules to apply invariants of a DomainModel, so only enforce Domain Rules! Nevertheless Great Video again! :)

[@zoran-horvat]

@@sotsch9280 Different layers can use different combinations of rules. That is the power of the Rules pattern, and also the reason why I included the role check as another rule. Why not have it, when rules offer a uniform interface for the verification?

[@sotsch9280]

@@zoran-horvat Yes basically good point! Isn't abstraction (Interfaces etc. like these "Rules") always and generally a powerful tool to uniform concepts? But not all concepts belong to the same abstractions. different layers deal with different problems. And Authentication + Authorization, for me, belongs to the application. A Rule that someone must be member of certain group is something I would check inside of a commandHandler directly. That some domain rules have to be applied i would either check inside ValueObjects or with this kind of Rule Pattern. This is just my way of separating things in my head. If the argument is "why not use this abstraction for everything", then we can throw away any kind of layers and eveything is crosscutting.

[@okcharles7]

@@sotsch9280 Did you see the namespaces? UserRoleTitleRule from Endpoints(the application layer), while others from Models(the domain layer). different layers are dealing with different problems.