Business Object (AKA Domain Object)

Business Objects are objects that correspond directly to concepts in the actual business the software is meant to represent and that encapsulate all decision making related to those concepts.

Often there is a chasm between how a business person perceives a business and how a software developer implements that business as software. Developers have to translate what is being said by a business analyst into the technology that is managing that business. Using object-oriented technology to create business objects representing the same structures business analysts speak of goes a long way towards improving the communication about and the design of an application.

Applications that represent a business are all about making decisions and providing support for users to make more decisions.  We try to have the code make as many of those decisions as it can. Examples include: Can a user login with this password? Can this Truck carry this Shipment? What’s that fastest route from Point A to Point B? The logic that determines the answers to these business questions is referred to as business logic. Business logic can be tough to figure out, easily done wrong, likely to change throughout the lifetime of the application, and is arguably the most important code written in an application. Duplicating this logic (on purpose or accident) is the source of much frustration and many bugs. Business objects are created to encapsulate this logic. The data used in these decisions are hidden away inside the object so no other code tries to make the same decisions, and no other code is affected when that data is changed to better support the logic.

There are many books and articles about how to come up with the best objects for a business, so I will not bother trying to sum up what volumes have been written about. In a nutshell, objects are created for any business concept that plays a part in the application’s requirements. All business logic is encapsulated in these objects, with each object answering the questions they are logically and usually best suited to answer.  For example, if user interface code wanted to know if a password entered is valid for a particular user then that code would ask the User object: user.IsThisYourPassword(password)

Business objects often cannot follow every heuristic of object-oriented design because of the nature of the common business application. For example, a standard OO tenet is that an object should not expose any of its data. However, in the common business application, business objects are created on the fly by administrators who need to see all that data. Attempts to uphold this rule without compromise can result in complex designs.

See also: What is a business object?