Explaining the business-object pattern

As the name suggests, a business object represents something in the real world and something associated with the business of the application. A business object is like an actor in an application use case. Examples of business objects include bank accounts, car insurance, college professors, students, employees, purchase orders, and payable or receivable accounts.

When it comes to simple applications with very little business complexity, that is, with few (or no) business rules, there may not be a need for a BO in the system. Better yet, a POJO entity that represents a database entity can be considered a BO. It is important to see the difference here. An entity or a POJO representative of an entity (such as a JPA POJO ) is closer to the technology and structure than to a business-model object. So, for this example, an entity such as a college student can also be considered a BO or an actor of a college student use case. In fact, in these simpler cases where the data model is sufficient for the business, there is no need to define a business object. 

In this case, we say that the data model related to the college student closely represents the conceptual domain model related to the student.

The application is often so simple that business-tier clients, such as a Session Fa?ade (or even presentation-tier clients), can directly access the data model through DAO. There is no need for a model object to handle greater complexity for the application business.