- I’d like to make one more posting on the topic of business rules, summarizing some of the different thoughts.
In reality, business rules appear in just about any layer. Here are some examples.
User entry validation may often be implemented in the User Experience. It can reside in a browser as JavaScript, in a GUI application as a control, or even in a console app as a function. We often know things such as data type, bounds of the data type, case requirements for string data. We use date pickers to enforce correct date entries. When selecting a date range we test to make sure the final date is equal to or greater that then start date. All of these things are essentially business rules. True, you don’t have to do them. However, not having validation on the client side leads to a clunky user experience.
On the complete other end of the spectrum you have your data design. If you are using an object storage, a good design is essential. Your data objects should control how all of the data fits together. In a relational database you would have a purchase order table and a child purchase order details table. In objects you have a purchase order object with a collection of purchase order details. Regardless of you persistence, it should implement your data integrity business rules. Let the SQL database enforce data integrity through referential integrity. Let you object database enforce your data integrity through encapsulation.
When it comes to more complex business rules that bring together the properties of multiple objects to make a decision, I really like the micro services design. Using micro services allows you to keep things tight, clean, without complication of things outside of the scope of the service. Due to the bandwidth of networks today, spreading processes out doesn’t have the negative impact found just a few years back. You can put business rules in your micro services that use only those resources within the boundary of the service.
If your application is complex enough to warrant access to multiple micro services, and implements business rules against more than one Micro Service, certainly a service specific to your application may implement the composite business rules.
The goal is to create a business rule in one location, and make it available to any consumer.
Here’s a challenge for you. How would you create business rules for data validation that may be used in the user experience and in your domain models, maybe even in the database? Here’s a simple example:
Create a business rule for Customer name with the following requirements.
- Allow Alpha/Numeric input
- Maximum length of 128
- All Alpha Characters must be Caplitalized
- Enforce this in a SQL Database Table, in the Domain Model, and validating user input.
Cheers,
Ben