A Line-Of-Business application or for short a LOB application is a one of the critical computer applications that are vital to running an enterprise. LOB applications are usually large programs that contain a number of integrated capabilities and tie into databases and database management systems. These applications are responsible for integrating three fundamental pillars of an enterprise, including Data, Processes, and Business rules. However, Application developers cannot tackle such an application just using a single paradigm, because of the data part being clearer than business rules and processes, the data-driven design is more seductive than other approaches such as an Object-Oriented one. Although complex parts of an application as a whole are better fits for a more complicated approach as object-oriented, there are some parts which have no complexity or change rarely, so using a sophisticated approach with more cost in development results in significant waste in the both current and the future development steps. In this article, I try to express a decision-making framework to select an appropriate approach to each part of an application.
First of all, you are required to know what are the sources of change in the software; changes raise from either the technology or the business. The approaches to handle them are not the same. Let’s deep dive into these types of changes.
The business side changes are a result of either strategy changes to benefit from more business competitive advantageous or organizational policy/ authority legislation reforms. Most of the time, these change requests are nontrivial and high priority; So it is crucial to apply them with as few side effects as possible. These circumstances cannot be handled unless using an advanced level of decomposition which the object-oriented paradigm is the first choice for. Nonetheless, all part of the business-related code does not have the same level of complexity and same importance during strategy changes. For example, suppose there is an invoicing application which helps a business to apply verity of discount strategies for each invoice, adding new discount calculation to the system which have not been in the past is a critical factor for helping the business to adapt its strategy in a competitive market to get a bigger share in the market. This change should neither take a long time nor have a side effect on the working system; while the security module for adding a new user or managing access level control are not critical in reforming business strategies.
Technology changes are the second reason to start the chaining in the source code. It might be evident that the technology changes should not have a side effect on the core business-related source code. From a solid business point of view, it’s not essential how a technological part of the application is implemented, works, or changes while it fulfills the nonfictional requirements. So changing the technology parts are not allowed to have a side effect on the core business. Applying such level of abstraction and encapsulation cannot be met unless playing in an object-oriented paradigm.
Now, a question might be asked; as applying the same level of design complexity to all part of an application might result in a needless complexity syndrome, how should I decide the best combination of complexity dosage? Below I try to explain a practical approach to solve this dilemma.
Step 1: Define and isolate your domain
As humankind the number of elements we can bear and handle in mind is limited, so if we have to encounter and solve a problem, we should decompose it to a small set of simple elements to overcome the complexity that might suffer our brain. Object-oriented principles, including Abstraction, Modularity, Encapsulation, and Hierarchy or for short AMEH, are essential techniques to dominate the real-world objects/concepts complexity. Applying these principles to a problem domain results in a simple model of the elements in the problem area, including essential data elements and business relationship between entities in the domain. The result of applying AMEH principles is a model with a focus on those part of objects data elements that might influence the problem and the solution. Abstraction minimizes the data elements of any object to vanish any unrelated, unnecessary information which might results in a domain complexity with no usage in solving the problem. For example, when a Customer Royalty System is the target of the project, the customers’ SSN might not be necessary as the customer Identification number is, while in a tax management system this might not be the case.
Moreover, encapsulation tries to hide the complexity of the implementation and details from other objects to minimize the relationship between them. It would not be nonsenses if we compate the objects’ world to a MAFIA band, as each object in the domain knows less about other objects it might be a survival from a change in the other objects, same as a gangster in MAFIA, whom might has more chance to live as he know less about others. For instance, suppose there is a trader object which contains a list of clients as an array and a portfolio object which needs to check if a specific name is in the trader’s client list, the first approach is traversing the array of the clients by portfolio and compare the name of each one with the target name, another approach is to add a method to the trader with a string as an input and a Boolean as output. In the first approach, the portfolio knows there is an array and a client with a name field in the trader, so it can access this data and find appropriate information; in contrast, the second approach let the portfolio to have no idea how the check is taken place. As it’s obvious the first method forces the portfolio to know tow information elements from the trader, the first one is the existence of an array and the second is to know there is a client with a property for his name. If any change occurs in the trader array data structure or client the portfolio might require to be changed as well, but in the second approach this information is hidden, and the portfolio has no idea how the search for the name is getting done, consequently portfolio is safe in case of changes in client and trader.
Hierarchy, this principle shows the required collaboration between objects to solve a problem, answer a question or do a computation, as message passing between objects in an object oriented application ( a.k.a. method calls) is the technique of performing a task, there might be a relation between these object to show they are related to each other. The controlled and supervised message passing between objects is called Hierarchy. It can be said, the hierarchy shows which relationships can be useful among a set of objects to not only protect encapsulation but also to allow the objects to have safe and low risk communication.
At the end, modularity is a technique to implement the abstraction and encapsulation by drawing a line around data and related behaviors, the smallest granularity of modularity is called Class, a template for an objects containing data and methods. Modularity is applicable in high granularity as packages. Here is more information about modularity in component level.
Applying AMEH principles to a problem domain results in a model which can be depicted by a UML class diagram containing classes as the real world objects/concepts representatives, focused on their essential data elements, this model contains a set of relationship between classes that show what messages are passing between them from a business point of view. It should be noted that in this level of modeling we focus on data (regardless of how these data might be persist) and business messages which are not methods of the objects and classes, this messages are those which business objects are exchange to perform a specific task. This model has most similarity to the real world business objects and their communication without applying any data persistence rule, normalization or principles. Not only there is no sign of data persistence principles but also there is no sign of object oriented or functional responsibility assignment technics in this domain model, because this model is your common dictionary with business guys who may have no idea about those technical aspects.
In the next part of this article I will discuss next steps of the recipe including:
Step 2: Identify the first-class citizens of your domain
Step 3: Choose an appropriate implementation approach to each category in the domain
Step 4: Identify the technology-related parts which might be a target of change