# Libraries for common business logic - best practice?

**URL:** <https://www.ruby-forum.com/t/libraries-for-common-business-logic-best-practice/123516>\
**Category:** Rails\
**Created:** [December 18, 2007, 11:30am UTC](https://www.ruby-forum.com/t/libraries-for-common-business-logic-best-practice/123516 "2007-12-18T11:30:33Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![reynar](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/e99b99/32.png) [@reynar](https://www.ruby-forum.com/u/reynar)\
**Post date:** [December 18, 2007, 11:30am UTC](https://www.ruby-forum.com/t/libraries-for-common-business-logic-best-practice/123516/1 "2007-12-18T11:30:33Z")

</div>

Hi,

I am working on my first large rails app and had a quick question of  
best practice.

It is essentially an ERP type application, tracking customer accounts,  
orders, and product inventory.

I am finding I am learning towards creating method libraries  
containing certain areas of business logic that refer to multiple  
models to achieve their result. They don’t necessarily create or  
modify existing resources, more make a decision based on some business  
rules.

Pricing for example. Given the complexity of product pricing models  
with customer specific pricing I was thinking of having some form of  
pricing engine that given a customer and a product returned the price  
chargeable.

I am also looking at doing similar things with despatch methods and so  
forth.

Essentially encapsulating a number of business rules which do not  
necessarily belong in the models.

Given the above I had considered creating modules within the lib  
directory and requiring them in the controllers as relevant.

Does anyone know of a better ruby or rails specific way of modeling  
this functionality?

Thanks, Andrew.