When you develop your software architecture, think of the problem as a set of business objects and their interactions. A business object is often defined as an “actor” or “participant” in the business logic for your organization. It can be any type of entity that can be seen in the processes that drive the business. Common business objects include things such as employees, customers, work orders, receipts, and account records.
These business objects can be modeled as a set of rules, work flows, and data flows.
Consider an example scenario where a customer calls to report a problem. The customer service representative might create a work order for a specialist to investigate further. A call log might be created and stored in a local database. The customer is a business object, as are the customer service representative, the work order, and the call log. Rules might also
govern these transactions. For example, customer attributes might dictate the priority of the work order. Data also must be fetched, created, and modified (also part of the model).
As you can imagine, a business object model is done in terms non-programmers can understand. It is the business perspective of the problem or solution. As such, the creation and revision of the model can involve any set of technical or non-technical people from your
organization.
Implementation
After a business model is created, it can be used to help you architect your software solution. As you can imagine, this type of model encourages object-oriented design. But how does it translate to your software solution? Here is a strict approach.
Each type of business object (BO) can be represented by an instance of a class. This class can (and should) encapsulate all of the attributes of that particular BO. Because each one has attributes that can be retrieved or changed as needed, these classes are often implemented as “data beans” with a simple set of entry points for creating or modifying attributes. The business logic is then written as interactions between these business objects. For interaction with data (such as a DBMS instance), the model includes data access objects (DAOs), which provide the interface to the data back end. The DAO provides a layer of abstraction so that the business objects do not need to understand the complexity of the back end. That advanced knowledge (for example, the specific format of a database's relational tables) can be encapsulated in the DAO.
Data flowing between parts of a process can be further
encapsulated into a data transfer object (DTO), which contains the data of interest (customer address) and nothing else.
Now, let us revisit our earlier example. When a customer calls in to report a problem, the customer service representative might need to look up the customer's address. The representative (being an “actor” in the process and therefore a business object) asks the DAO for this information. The DAO understands the complexity of the back end, fetches the data,
and returns a DTO that contains the customer's address.
Of course, the real-life implementation of code that is based on the business object model is rarely as perfect as the preceding description asserts. For example, it might not be feasible to fully encapsulate a business object into a single class. Performance considerations or
third-party software might impose restrictions on your design. Regardless, the model can still be used to help partition the design into relevant business objects and maintain a logical and meaningful separation of work.
Advantages
As you can see, the usage of a business object model helps the solution follow many of the preferred practices that are outlined in this chapter. For example, the model tends to enforce a strong notion of modularization because each BO, DTO, and DAO contain the information that it needs to complete its own necessary tasks. Further, each object does not need to contain detailed knowledge about tasks that are performed by other objects (single responsibility). In
a good design, parts of the model can be replaced or modified without impacting the rest of the solution (loose coupling), which results in code that is more maintainable, reusable, and flexible.
In addition, modeling with business objects allows you to quickly identify dependencies when making a change. In this example, if the DTO retrieves a customer's address changes, what other objects might be affected? Similarly, it can help identify performance-sensitive modules within the solution.
As mentioned earlier, the business object model itself is not programmer speak. It is not class diagrams, function prototypes, or XML. In fact, it is often done with stick-men and circles. As such, just about anyone can contribute to the model by identifying interactions, associations, and rules for the model.
Most importantly, this approach forces the software architect to keep a business-level perspective on the problem. After all, when designing a software component, it is essential to understand how it fits into the big picture. This understanding is sure to result in a better software solution.