Let's say that we want to increase the complexity of the system (let's say the system needs to contain more functions, for example). Let's also imagine that a college has members that consist of professors, employees, and students. Suppose there is a member entity that almost matches the member table in the related database. In addition, we know that professors, students, and employees are members of the college, and for that reason, they have common characteristics that every member should have. However, the professor, student, and employee also have their own characteristics. A professor's main characteristics are that they are a member who teaches and has a Masters or PhD qualification.

Similarly, a student has their own characteristics, such as enrollment in college and the number of courses they are enrolled in. Professors and students will both also have relationships with other entities. For this, we can architect the application in terms of the database and create four tables—Member, Student, Employee, and Professor. We can establish a one-to-one relationship between Student and Member, Professor and Member, and also Employee and Member. In any implementation, we can have four JPA entities related to these tables.

However, a professor is an actor of the teaches discipline use case with some business rules. This more complex professor object combines the Member and Professor entities. We can then define a ProfessorBO (business object) object, which is the combination of the Member with Professor. In addition, ProfessorBO may have methods that provide a richer behavioral value for the object because these methods are used in the use case. Without such methods, the object becomes an anemic object. However, it could be said that this is still a relatively low complexity. Consequently, we can think of a use case that shows all the disciplines taught by a professor, or a professor's skills that are necessary to teach particular disciplines. Here, we have another table and entity: Discipline.

In addition, a student is related to a particular course. This is another use case with one more entity: Course. The possibilities conceived for an academic system are innumerable and are far from being a simple data-model system. Business objects can be used for complex use cases. 

The following diagram shows the Professor, Student, and Employee as more complex objects:

This scenario is just one of several possible implementations. In our small example, we consider the existence of an object called ProfessorBO, which uses three entities (Professor, Member, and Discipline) and has associated business methods.

One could argue that there would be no need to have ProfessorBO. We could have a Professor Facade that could implement the Session Façade pattern with business methods and would also manipulate the different combined entities using a DAO (for the execution of CRUD operations).

We can agree with this architecture and, depending on the complexity of the system, it may even be the best alternative. However, we chose this architecture, which clearly illustrates the definition and use of the BO pattern, so let's continue with our example.

Therefore, a ProfessorBO object represents a professor who is an actor for one or more use cases related to the conceptual professor model.