Understanding Business Rules vs. Trivial Validation in .NET C#

Admir Mujkic
2 min readMar 5, 2024

--

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#.

Understanding Business Rules vs. Trivial Validation 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.

Online Book Store Service Class

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.

Example of Record BookId

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.

--

--

Admir Mujkic

Admir combined engineering expertise with business acumen to make a positive impact & share knowledge. Dedicated to educating the next generation of leaders.