Where should the business rules be implemented? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

开发者_开发知识库 Improve this question

1) Should them be implemented in a module over any set of their methods? 2) Should them be implemented in a special class where every method test a specific business rule?

Also... could you recommend me any good bibliography on the issue?

UPDATE:

"A business rule is a rule of a business, company, or corporation. It is a rule that defines or constrains some aspect of business and always resolves to either true or false" Wikipedia definition.

---

First you'll have to have a clear definition of what a "business rule" is. There are a bevy of candidates:

1. Information about your products.
2. Rules regarding sales that depend on time, location, customer, product, phase of the moon (aka closing date of the month), season, etc.
3. User roles (e.g., normal versus preferred customers, etc.)
4. Rules around accounts payable and receivable
5. GAAP rules

What exactly do you mean? It's a vague question that can be quite large if you let it.

You have lots of choices as to where they go in your code:

1. Data driven, stored in databases
2. Expressions in a Rete rules engine.
3. Middle tier classes if you're writing OO.
4. Properties or configuration files if you're doing declarative programming.
5. Executable rules expressed in something like JavaScript.
6. In your ERP, MRP, A/P and A/R systems.
7. Fronted by web services that your apps compose together.

Do you see the problem you're opening up? Your question implies that you have a well-defined problem and expect a simple, neat answer. The truth is that it's a broad topic.

---

This is quite a generic question and hard to answer -- but I'd say take a look at Behaviour Driven Development as a way of keeping business rules at the heart of your development.

---

I suggest you investigate the MVC paradigm - Model View Controller. There should be no business logic in the view, it should all be in the model.

---

The answer depends on multiple factors like

• should customer make changes to the rules?
• How often the rules change?
• Should updated rules be deployed without restarting the application?

If answer is YES to all of them above then a rules engine (drools, ilog etc) is what you are looking for to implement your rules

If your answer is NO then the alternative is to to model the rules in code keeping below in mind

• encapsulate 1 business rule in its own class so that it can be independently tested, customized and updated
• name the rule the way business mentions it (ubiquitous language)
• Learn about the specifiation pattern (domain driven design). I think this way of expressing rules is very intuitive and explicit

E.g. copied from here

EligibleForDiscountSpecification isEligibleForDiscountRule = new EligibleForDiscountSpecification();
isEligibleForDiscountRule .IsSatisfiedBy(customer)

---

Business Rules best practices state that the rules should be pluggable components. A minimalist approach would consist in coding them in a dedicated library, and proceed with Dependency Injection, or Reflection... Maybe you should investigate about Contracts Driven Development too, and look at www.businessrulesgroup.org/brmanifesto.htm to begin.