How to tackle complex business rule and logic

Business logic doesn't go into the database

If we're talking about multi-tier applications, it seems pretty clear that business logic, the kind of intelligence that runs a particular enterprise, belongs in the Business Logic Layer, not in the Data Access Layer.

Databases do a few things really well:

1. They store and retrieve data
2. They establish and enforce relationships between different data entities
3. They provide the means to query the data for answers
4. They provide performance optimizations.
5. They provide access control

Now, of course, you can codify all sorts of things in a database that pertain to your business concerns, things like tax rates, discounts, operation codes, categories and so forth. But the business action that is taken on that data is not generally coded into the database, for all sorts of reasons already mentioned by others, although an action can be chosen in the database and executed elsewhere.

And of course, there may be things that are performed in a database for performance and other reasons:

1. Closing out an accounting period
2. Number crunching
3. Nightly batch processes
4. Fail-over

Naturally, nothing is engraved in stone. Stored Procedures are suitable for a wide array of tasks simply because they live on the database server and have certain strengths and advantages.

Stored Procedures Everywhere?

There's a certain allure to coding all of your data storage, management and retrieval tasks in stored procedures, and simply consuming the resulting data services. You certainly would benefit from the maximum possible performance and security optimizations that the database server could provide, and that's no small thing.

But what do you risk?

1. Vendor lock-in
2. The need for developers with special skill sets
3. Spartan programming tools, overall
4. Extremely tight software coupling
5. No separation of concerns

And of course, if you need a web service (which is probably where this is all heading, anyway), you're still going to have to build that.

So what is typical practice?

I would say that a typical, modern approach is to use an Object-Relational Mapper (such as Entity Framework) to create classes that model your tables. You can then speak to your database through a repository that returns collections of objects, a situation that is very familiar to any competent software developer. The ORM dynamically generates SQL corresponding to your data model and the information requested, which the database server then processes to return query results.

How well does this work? Very well, and much more rapidly than writing stored procedures and views. This generally covers about 80% of your data access requirements, mostly CRUD. What covers the other 20%? You guessed it: stored procedures, which all of the major ORMs support directly.

Can you write a code generator that does the same thing as an ORM, but with stored procedures? Sure you can. But ORMs are generally vendor-independent, well-understood by everyone, and better supported.

Is it something particular or is it something more general?

Typically, business rules are of the form "if(condition) then action", while business logic tends to describe a larger set or a sequence of both business rules and other logic. So "business logic" is more general any code that implements logic specific to your problem domain, where "business rule" is a specific concept.

Examples (pseudo code):

// business rule
if(sales-revenue > 1000) then send("thank you")

//business logic
sales-revenue = sum(all items in order)
bonus-points = sales-revenue * .1
executeBusinessRules()

Do I need to learn UML?

No, you don't have to learn UML. But it may help to visualize your solution, and in fact make it easier to describe because you have to think it through more thoroughly - if you can't draw it in UML, probably something is not quite right yet.

Business rules can be nicely described with state charts or activity diagrams, and business logic in general can be described in sequence diagrams or activity diagrams.

Does the fact that I use MVC affects the way I'll describe it?

It shouldn't - if it does, this may indicate poor separation of concerns. MVC is a way to organize your code, or more specifically to keep aspects of your implementation separate (aka 'separation of concerns'). The M(odel) in MVC is what should implement your business logic.