A healthy object-oriented recipe for business applications -Part2

In the first part of this topic, I described how can we start a software problem from scratch, that step results in a simplified perspective from the real-world objects and concepts which helps to omit a part of problem intrinsic complexity by focusing on a limited part of the data properties and business relation between extracted class in the model; we called this model domain model or conceptual model. Here I describe the remaining steps.

Step 2: Identify the first-class citizens of your domain         

Firstly we have to confirm a fact in software development. The fact of Conservation of mass. In a business application, the most long-lived module in the application is the business logic module, where the business rules are business processes are controlled. Although other modules as a persistent module, user interface are essential for a system to work well, they are the place of change due to technology and nonfunctional requirements and constraints. The reasons of changes in the business logic modules are different than other modules; the first set is rooted in business rules and business strategies changes while the second categories most of the time are due to technologies changes. As a result, we focus on this module and categorize its classes in “Very Important” and “Important” groups.

“Very Important” classes in a conceptual model are those that reflect the competitive advantageous business areas. Important classes are supporting classes which prepare and provide prerequisites of the first category to work.

The most critical characteristics of “Very Important” classes are the number of changes and verify they have in their implementation. Another attribute of this category is that the behaviour of some of the classes’ changes based on a situation as their type or another factor.

Besides, these classes hold essential data in applying business decision making and business rules control.

On the other hand, most of the times “Important” classes are just data containers with a small no particular functionality to do.

Step 3: Choose an appropriate implementation approach to each category in the domain

As the domain logic module is the heart of the application and rapid change adaption is vital to adjust application with the business strategy, the “Very Important” classes as mission-critical objects are subject of changes. Moreover, we know the best approach to face the changes in software development design is a divide and conquer approach using object-oriented design.

Instead, for “Important” classes in the conceptual model, we can choose different methods.

As Martin Fowler states, there are three patterns for domain logic layer design. “Transaction Scripts,” “Table Module,” and “Domain model.”

“Transaction script” is the most uncomplicated approach to implement the business layer; this pattern works very well when you just need manageable CRUD action on data with a bit of validation on them. For example, when it’s required to manage some base data and lookup in an application which there are no significant business rules and computation for it, the best approach is transaction script. Some classes shape around use cases and coordinate the steps of related actions. Although there are some object-oriented design tricks to simplify these scripts’ implementations these classes are just a bunch of methods with no state. These methods get the data as input, do some validation then apply the persistence action.

Sometimes there are cases which there are a few business rules shaped around the persisted data model. It means in a relational data persistence approach; you can map each responsibility to an object that same as a table in the database, In this case, Fowler suggests choosing “Table Module” pattern, a pattern which forms responsibilities around persistence data model as tables in a relational database. A great implementation of this mindset is “Typed Data Set” in Microsoft .net framework.

“Transaction script” and “Table module” are the best candidate for those part of the conceptual model which has no majestic responsibility to do in the business and are just supporting domain classes. As agility and change adoption is none trivial in competitive markets, those part of the application supports the strategic part of the application must be most flexible to adopt changes with least side effects. Suppose, we are working on an application for a grocery store Chains Company that its strategy is to offer the customers a verity range off discounts, the discount calculation formulas change frequently and most of the time they need to develop them in the sale system of the company, in such a case it’s required to be able to change the source code of the application. Simplicity, agility and flexibility are very important in this part of the application, otherwise adding new discount strategy from the business side ends in chaos in the sale system, a system with a large number of errors.

Step 4: Identify the technology-related parts which might be a target of change

Most of the time, there are some steps in the business processes need to communicate without the application universe, for example, sending an email, call a Tax web service, etc. However, this step could be an essential step in the business, and this must not be any dependency on concrete technologies as Web services, SMTP services, etc. So regardless of business layer strategy, such dependencies must be reversed to have a maintainable, extendable, and testable code.

For sum up, while developing a LOB application, the most toxic approach is to start from a relational data model which bios the development team mindset and suffer business guys in communications with the team. Despite that data and its persistence are not ignorable in designing an application, it cannot be called the first and most crucial step in the design process. To avoid needless complexity, fragility, rigidity, and other design smells which rot a software it’s required to start from another point, the conceptual model. Using the right approach in the business layer not only save time and money in the first stage of the development but also save them in the maintenance and change storms.