Writing Business Logic: Why follow Patterns / Practices?

Posted by Sambeet Patra under .NET Software Development, Software Architecture

In this post I will explain tips to expose functionality and abstract details of your business logic. However, instead of focusing on the technical details I will focus more on the need to use practices. I will take you through a real life example to explain why it is important to put significant thoughts into this concept.

Before we start, let me explain the scenario I am trying to address. Often people challenge the need for patterns / practices / extensive architectural analysis for software development. The common response you get from developers is “So, whats new? I can write code to do that myself?”, or something like “How do I benefit from implementing this? It sounds so theoretical?”. These are all fair questions as long as the development work is done by an individual or by a small group of developers. The problem we face while working in enterprise deployments are (A) we have to manage a team environment where potentially large groups of developers will be working on the same project and (B) team members will change from time to time. When we take these factors into consideration, the importance of acrchitecture / patterns and practices and programming standards increase significantly. That said, lets jump straight into our example which will match very closely with typical day to day software development process. I will use C# / .Net to demonstrate the examples. But the concept is applicable to all languages / environments.

Consider a banking application that is being developed by your team. One of the developers is given the responsibility to implement business logic for money transfer. The feature involves withdrawing money from one account and deposit it to another account. While implementing the logic, the developer also wrote a utility to audit the transaction. So, the final implementation will look something like this

public class TransferManager
{
public void Withdraw(int accountId, decimal amount)
{
}

public void Deposit(int accountId, decimal amount)
{
}

public AuditTransfer(int fromAccount, int toAccount, decimal amount)
{
}
}

The developer has written methods to implement each step in the business process. Now, before even this module was put to use, the developer moved to another team and now you have a module developed by some one without a lot of documentation. Well, in a happy day situation, you will have ample documentation for all the work being done, but in reality documents do not provide the necessary information [or they simply do not exist!] in many cases. So what do you do now? As a user of this module, you start analyzing what has already been done and you try to map the work to the business functionality. So, you would use the Withdraw and the Deposit method and will not use the AuditTransfer [as, from the looks of it, it does not sound to be a part of money transfer process].As a result, you are likely to make mistakes due to lack of knowledge of the existing code.

This is where I make my first point. Always expose methods depicting the complete business process. This is because (A) you do not want the client to guess how they need to use your component. If you write wholesome functions, the client does not need to understand the details and needs to call only one function. So you will encourage writing code like the following:

public class TransferManager
{
public int TransferAmount(int fromAccount, int toAccount, decimal amount)
{
}
}

public class TransferUtility
{
public void Withdraw(int accountId, decimal amount)
{
}

public void Deposit(int accountId, decimal amount)
{
}

public AuditTransfer(int fromAccount, int toAccount, decimal amount)
{
}
}

Here, the manager class is supposed to expose methods for the clients and the utility class is used by the manager class to orchestrate business process details. But, we are not done yet. What is the guarantee that in future some client will not directly use the utility class? This can happen due to lack of knowledge right? This is where I will make a slight modification. I will declare all classes that are not manager classes as internal. The idea is, expose only those methods that are to be used by the client and Hide everything else.

public class TransferManager
{
public int TransferAmount(int fromAccount, int toAccount, decimal amount)
{
}
}

internal class TransferUtility
{
public void Withdraw(int accountId, decimal amount)
{
}

public void Deposit(int accountId, decimal amount)
{
}

public AuditTransfer(int fromAccount, int toAccount, decimal amount)
{
}
}

I can go on and talk about factory pattern / facade pattern etc. But, I think if you understand the philosophy of team development, you will be using these pattens without even knowing that you are using these. After all, patterns / practices are results of right thinking!