# Domain Model Based Design of Business Process Architectures
## 5 The dBPA Method
### Procedure  
The dBPA method has five--generally speaking--sequential steps, as shown in Figure 7. Their descriptions are illustrated via an example of a _Retail Company_ that manufactures and sells items to customers that place national or international purchases. 1. **Prepare domain model**. This step enables applying subsequent steps of the method directly. This is achieved by ensuring that the domain model \(w\) complies with some specifications, as stated in the following. * For each association \(a\in A\) whose direction \(dir\) is not shown, show it. * For each association \(a\in A\) whose name _assoc_ is formulated in a passive way (e.g., _is hired by_), formulate it in an active way (e.g., _hires_), and adjust the direction \(dir\), if necessary. * For each power-type \(c_{power}\in C_{power}\) transform it into a semantically-equivalent hierarchy \(h\) in the following way: considering there exists an association \(a\in A\) between \(c_{power}\) and \(c\in C\), replace \(a\) by the hierarchy \(h\in H\) such that \(c\) is the super-class and \(c_{i}\) are the sub-classes, where \(i\) indicates the different objects of \(c_{power}\). _In the example._ The domain model in Figure 3 complies with the aforementioned specifications. 2. **Identify business entities. ** This step allows identifying the set of business entities \(B\) that will be considered in the remainder of the method. * Each domain model class \(c\in w\) corresponds to a business entity \(b\in B\), with the exception of sub-classes partaking in a hierarchy \(h\). Sub-classes can be mapped into particular cases of business entities and thus are, conceptually, business entities. However, they are discarded from the set of business entities to be analyzed in the remainder of the method. _In the example._ Business entities for the retail company are Customer, Courier, Invoice, Purchase, and Purchase item from the domain model in Figure 3. International purchase is discarded from the set of business entities due to being a sub-class. 3. **Identify states of domain model classes. ** Business entities may have simple or non-trivial behavior, depending on the number of states it may transit during its lifetime. * For each business entity \(b\in B\) with non-trivial behavior, its set of states \(S\) can be defined in the OLC \(l\) for the class \(c\) on which the business entity is based. Whenever no OLC is available or it is incomplete, the set of states \(S\) can be determined by the following (more than one of the options can be used): * The sub-classes partaking in the state-based dynamic hierarchy \(h_{s}\in H_{s}\) of which \(c\in w\) is the super-class (whenever \(H_{s}\
eq\emptyset\)), * The possible values of state attribute \(j_{s}\) of data class \(c\in w\) (whenever \(Z_{s}\
eq\emptyset\)) * The possible values of the state attribute \(j_{s}\) of the corresponding data class \(c\in dd\) whenever a complementary data dictionary \(dd\) is available for \(w\), * Domain-expert knowledge,  
Figure 7: Domain-based Business Process Architecture (dBPA) method. For each business entity \(b\in B\) with simple behavior (or no state information available), its set of states \(S\) corresponds to the set of states \(S_{g}\in l_{g}\). It is also important to ensure that:  
* The set of states \(S\) of a business entity \(b\) include an initial state \(s_{i}\) and a non-empty set of final states \(S_{F}\). * After identifying the set of states for each business entity \(b\in B\), all involved models are updated as needed for ensuring that they are consistent with one another. _In the example._ The set of states of Invoice is [_i, issued, paid_] and of Purchase item is [_i, with stock, without stock, canceled_]. In both cases, they were derived directly from the data dictionary shown in Figure 3. The set of states of Purchase is [_i, placed, delivered, closed_], which was also derived from the data dictionary but in a more indirect way. The set of states of Customer is [_i, active, inactive_] and was derived solely from domain-expert knowledge.