Business Object

See Core J2EE Patterns, 2nd Edition for full description of this pattern and its strategies.

Problem

You have a conceptual domain model with business logic and relationship.

Forces

• You have a conceptual model containing structured, interrelated composite objects.
• You have a conceptual model with sophisticated business logic, validation and business rules.
• You want to separate the business state and related behavior from the rest of the application, improving cohesion and reusability.
• You want to centralize business logic and state in an application.
• You want to increase reusability of business logic and avoid duplication of code.

Solution

Use Business Objects to separate business data and logic using an object model.

Class Diagram

Sequence Diagram

Strategies

• POJO Business Object Strategy
• Composite Entity Business Object Strategy

Consequences

• Promotes object-oriented approach to the business model implementation
• Centralizes business behavior and state, and promotes reuse
• Avoids duplication of and improves maintainability of code
• Separates persistence logic from business logic
• Promotes service-oriented architecture
• POJO implementations can induce, and are susceptible to, stale data
• Adds extra layer of indirection
• Can result in bloated objects

Related Patterns

• Composite Entity
  You can implement Business Objects using local entity beans in EJB 2.x. Local entity beans are recommended over remote entity beans to implement Business Objects. Composite Entity discusses the details of implementing Business Objects with entity beans.
• Application Service
  Atomic business logic and rules related to a single Business Object are typically implemented within that Business Object. However, in most applications, you also have business logic that acts on multiple Business Objects. You might also need to provide business behavior specific to use cases, client types, or channels on top of what the Business Objects inherently implement. Using Application Service is an excellent way to implement business logic that acts upon several Business Objects and thereby provides a service encapsulation layer for the Business Objects
• Transfer Object
  You can use Transfer Objects to carry data to and from the Business Objects. Some developers are tempted to use Transfer Objects as the internal state representation for Business Objects. However, a Business Object wrapping a Transfer Object is not recommended because it violates the intention of the Transfer Object pattern and tightly couples the two types of objects. (See Business Object Wraps Transfer Object (Page 390)).
• Data Access Object
  You can use Data Access Objects to facilitate Business Objects persistence, in implementations that use custom JDBC mechanisms.
• Domain Store
  You can use Domain Store to provide Business Objects persistence to leverage the power of custom implementation of transparent persistence mechanisms, similar to standard JDO implementations.
• Transaction Script and Domain Model [PEAA]
  Transaction Script discusses a procedural implementation of business logic and Domain Model discusses the object-oriented implementation. While the Domain Model and Business Object pattern are very similar, the term business object is more commonly used by developers and architects in the field and is more precise. We have seen extensive use of the term business object in numerous projects that fall in line with the concepts outlined in this pattern.

Excerpted from Core J2EE Patterns, 2nd Edition. See the book for full description of the pattern including class diagrams, sequence diagrams and sample code.