TDD and Business Rules (1)

This month I was working in an agile team, developing a non-public system. One interesting feature was that the system allows the creation and existence of domain entities with “invalid” states. That is, they are “invalid” in context: the product owner wants to build a flexible system that reflects the business reality, instead a more strict one that avoids the “invalid” states. But he wants to see which are the current “invalid” states, so the system can generate and show a list of Findings (that is the term we use in the system).

I want to explore the “TDD way” to build such feature. To be more specific, I will describe a similar domain with simplified findings.

Let be an Order. The Order has one or more Order Items. Each Order Item has a Product, Quantity, Price. Each Order has a Customer. There are business rules that describes what are the “invalid” states. Some examples:

– An Order for a Customer category Y cannot have a total amount > X.
– An Order must have one or more Order Items.
– Order Items should have Quantity > 0.
– Order Items should have Price > 0.
– Product P should have Quantity > Minimal Quantiy in each Order Item.
– Product P has a Price, and its Order Items cannot have a Price < Product Price * 0.80.
– and so on…

So, Order can be created and stored having state that broke some rules. It’s OK. The Order is NOT refused by the system. Product Owner wants to have (at any moment) the list of broker rules, the Findings.

The business rules can change, and new ones can be defined. It’s not defined how to do this (maybe, adding code, or writing an expression, Product Owner doesn’t care yet). In the initial version, the business rules can be fixed. In a second version, some rules can be applied to some orders (i.e., some rules could be applied to Orders where their customers are in Canada). Product owner wants to have: findings per order, findings per product, findings per customer.

Then, in this post series, I will show a way to build the proposed applications, using TDD. To simplify the example, no UI or persistence will be used: only domain objects and their relations in a graph. I want to explore how, using TDD, the rules and their execution emerges from the simple use cases. I will use a GitHub project, and .NET with C#.

Keep tuned!

Angel “Java” Lopez

2 thoughts on “TDD and Business Rules (1)

  1. Pingback: New Month’s Resolutions: August 2012 « Angel ”Java” Lopez on Blog

  2. Pingback: Resoluciones del Nuevo Mes: Agosto de 2012 - Angel "Java" Lopez

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s