Where to keep business logic

We as software engineers read the code more than we write. Sometimes we end up legacy code hard to understand and maintain it. Recently we encountered a problem in extending a business logic, where we added the business logic to business logic tier, only to find that the business logic was never applied. The implementation in the business tier is correct, however we are not getting the results we wanted. Upon further investigation and debugging, the persistence  tier is just adding the default values no matter what business tier is asking to do. The legacy code worked perfectly at that time it was written because it was called only once from business tier and it was setting default value explicitly (basically the default behavior was duplicated in persistence tier).  The moment we tried to reuse the code with non-default behavior it started to giving incorrect results. We found the problem and refactored the code to remove the default behavior from persistence tier and added the required logic in the business tier.

This incident thought me one valuable lesson. Each tier in the architecture should do what is supposed to do. Nothing more and nothing less. If you observe a tier is doing more than what is supposed to do, remove the extra stuff, place it where it belongs. It’s like Single Responsibility Principle but at a higher level.

This entry was posted in Uncategorized and tagged , , , . Bookmark the permalink.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s