Understanding Business Rules vs. Trivial Validation in .NET C#
Admir Mujkic
Solution Architect | Engineering Leader | Driving Scalable, Innovative Software Solutions and Technical Leadership
The realm of software development brings with it the challenge of classifying code as trivial validation versus business rules. This becomes paramount as we venture into dealing with business logic and data validation. The distinctions between the two code categories dictates not only how we write our code, but also the flexibility and scalability of our systems. In this article, I��m going to demonstrate some practical use cases in .NET C#.
Example Overview
For this example, imagine a simple online bookstore system. We��ll use this scenario to explore different logic embedded in two lines of code, referring to a book service implemented within the system.
Explanation
The check if (bookId <= 0) is a form of trivial validation. It��s static, unlikely to change, and checks for basic correctness of input data.
The line if (!_bookInventory.IsBookAvailable(bookId, quantity)) embodies a business rule. It��s dynamic, depending on current state of the system (i.e. the book inventory), and may change over time based on business needs.
��Ӣ�Ƽ�
Redefining Validation with Strong Types
Our next progression towards cleaner designs is to introduce a strong type for bookId to encapsulate this validation logic, to make our system a little stronger.
Now, ProcessBookOrder can be refactored to accept BookId as parameter, lifting trivial validation into a higher level in the system, to allow that method to focus on business rules.
For the end...
One of the ways to achieve long-term maintainability in the software world is to reduce the number of reasons for a piece of code to change. Understanding and appropriately implementing business rules versus trivial validation goes a long way towards reducing the reasons, and results in cleaner, more maintainable, and scalable code.
By wrapping up invariants in strong types and ignoring all checks for invariants until we are ��forced�� to, we focus our attention on the ��interesting parts�� of our system, core business logic. We��re also giving our systems the freedom to grow and evolve with the business they��re serving.
.NET Software Engineer
1 ��Most bugs are caused by the arrival of wrong data in the flow, but developers normally use a defensive approach as a prevention, as in your first example. However, this only creates additional problems because the check is not placed in the right domain, that is, incorrect business data is allowed to be created. For example, to allow the creation of a price without a currency.
.Net C# Developer
1 ��Where should you perform validation if you have say a Web UI hitting an API hitting the application layer which works with domain objects and eventually the database?
Microsoft MVP | Follow me to get better in .NET, C#, and ASP.NET Core | codingsonata.com | Technical Product Head at Aramex
1 ��It is important to differentiate between the regular input validation and the business rules, and both ways these should remain on separate classes and injected into the caller to guarantee neat implementations and clean solutions. Also the early return strategy you've included in your code snippets are greatly helpful to make the code cleaner and highly readable. Well-done Admir.
I help .NET developers advance their careers by mastering the latest tech and industry best practices.
1 ��In Web APIs, where do you put business, and where do you put validation rules?
Great insight on the importance of distinguishing between business logic and validation checks for maintainable and scalable code!