Business Entity in Component-Oriented Architecture
Intro
So, what is Entity, anyway ? Many folks know they should program using components but smaller part is able to define what Business Entity is up to or can distinguish between Entity and other types of Application components for example Infrastructure Components or Logging Components or User.
Definition
Start from the Use Case. Then translate the Use Case to the Business Process (What customer is generally gonna do here and there using our Application). After scetching a bunch of Business Processes we finally can define Business Entities:
Business Entity is an independent role in a Business Process.
If you can define an independent role for it - it is Entity (for example Order vs. OrderItem in ProcessOrder business process).
Characteristics
- Business Entities Provide stateful programmatic access to business data and (in some designs) related functionality.
- Business Entity is passed as I/O parameter of business processes.
Thus - Entities can be serializable, to persist the current state of the entities. For example, applications may need to store entity data on a local disk, in a desktop database if the application is working offline, or in a Message Queuing message or travel via HTTP and Remoting.
Business Entity IS NOT
- Infrastructure Component. All functionality that stands outside Use Cases is implemented in Infrastructure Components. Don't mix Business Entities with Infrastructure Components.
- SMTP, FTP, etc protocols implementation configuration/process/helper classes - are NOT Business Entities.
- Logging components classes. This can be implemented as Logging Configuration, Logging Data Access, etc - are NOT Business Entities. Logging is a bit tricky. For example if you want to audit Business Entity behaviour - need to translate Business Entity into Logging Component before you write to Log. This is because in this case Logging Component is actually a time-stamped copy of some Business Entity component stored in some Logging storage.
- User profile component - is not Business Entity. Anyone who logins and has preferences - is NOT a Business Entity. User Profile could be implemented as Customer, Employee, User, etc. Thus - Authentication and Authorization related components are not related to Business Processing.
Entities do NOT
- Access the database. All database access is provided by the associated Data Access Logic Component. Rule of Thumb - each Entity will have exactly one Data Access component per single data storage.
- Initiate any kind of transaction. Transactions are initiated by the application or business process that is using the business entities. Actually this means that Business Entity does not implement any kind of functionality associated with Business Logic.
Entity Schema
Business entities can be built from data that has complex schemas. Single Entity can be implemented via muliple classes and collections. For example, OrderEntity is formed from Order, Product, OrderItem classes formatted and related to each other.
Related reading
I find both articles only partly useful, but whatever...
Saturday, March 3, 2007 7:01 AM