You have a conceptual domain model with business logic and relationship.
- You have a conceptual model containing structured, interrelated composite
- 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
Use Business Objects to separate business data and logic using
an object model.
- POJO Business Object Strategy
- Composite Entity Business Object Strategy
- 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
- 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
- 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
- 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.