A business object is an entity within a multi-tiered software application that works in conjunction with the data access and business logic layers to transport data.
Business objects separate state from behaviour because they are communicated across the tiers in a multi-tiered system, while the real work of the application is done in the business tier and does not move across the tiers.
Function
Whereas a program may implement classes, which typically end in objects managing or executing behaviours, a business object usually does nothing itself but holds a set of instance variables or properties, also known as attributes, and associations with other business objects, weaving a map of objects representing the business relationships.
A domain model where business objects do not have behaviour is called an anemic domain model.
Examples
For example, a "Manager" would be a business object where its attributes can be "Name", "Second name", "Age", "Area", "Country" and it could hold a 1-n association with its employees (a collection of "Employee" instances).
Another example would be a concept like "Process" having "Identifier", "Name", "Start date", "End date" and "Kind" attributes and holding an association with the "Employee" (the responsible) that started it.
See also
- Active record pattern, design pattern that stores object data in memory in relational databases, with functions to insert, update, and delete records
- Business intelligence, a field within information technology that provides decision support and business-critical information based on data
- Data access object, design pattern that provides an interface to a type of database or other persistent mechanism, and offers data operations to application calls without exposing database details
- Data transfer object, design pattern where an object carries aggregated data between processes to reduce the number of calls
References
External links
- A definition of domain model by Martin Fowler
- Anemic Domain Model by Martin Fowler