AOSD: Use AOP to implement business logic

Synchronized from http://www.blogjava.net/AndersLin/archive/2006/06/15/53079.html

(Below is Javaeye The post mentioned above has some meaning, so I transferred it to the blog. I have some new ideas about domain and AOSD)

The system developed by the application domain usually stores the logic in the domain service layer, while the domain service performs two tasks:
1. communication with the presentation layer refers to converting the plane data (VO) of the presentation layer into the domain object associated with the domain object, and converting the calculation result of the domain object into the plane data (VO) return to the presentation layer;
2. Use Case to schedule business logic.

The following describes how to use case.
Generally, use case describes four types of business flow: basic flow, alternate flow, exception flow, and extension flow.
Although business flow may contain many domain objects, because each use case object has a strong domain logic, a primary domain object can be extracted through analysis. Then reorganize and convert the BP design documents from BA or pm so that the basic flow is based on the main domain object, and the alternate flow, exception flow and extension flow are based on other domain services and domain objects (including util objects, of course). Finally, alternate flow is implemented using AOP, exception flow and extension flow are organized with basic flow at the service layer.
When you use AOP to organize use cases, it is different from using AOP to organize technical problems (such as logs, permission checks, and transaction processing.
We do not care about the join pointTarget object, target method, and entry parameters. For example:
 

Public   Class Bankserviceimpl Implements Bankservice {
Public   Void Transfer (useraccount SRC, useraccount Dist,
Bigdecimal amount) Throws Exception {
SRC. Subtract (amount );
Dist. Add (amount );
}  
// Other code goes here
}  

< Bean ID = " Bankservice "   Class = " Org.
Springframework. transaction. Interceptor. transactionproxyfactorybean " >
< Property name = " Transactionattributes " >  
< Props >  
< Prop key = " Transfer " > Propagation_required </ Prop >
</ Props >  
</ Property >  
</ Bean >  

We do not care about parameters, or use parameters to identify and distinguish our method entries in some areas of method overloading.
But when we use AOP to organize use cases, weFocus on the target object, target method, and entry parameters.Because the method to be woven by AOP is that another use case is another biz flow. (This is not much discussed in AOSD, as mentioned in chapter 12 12 12. 4)
For example, we need to send a text message to the customer after the transfer is successful. So no AOP is used.CodeWe write as follows:

Public   Class Bankserviceimpl Implements Bankservice {
Public   Void Transfer (useraccount SRC, useraccount Dist,
Bigdecimal change) Throws Exception {
SRC. Subtract (change );
Dist. Add (change );
Smsservice. sendsms (SRC, change );
Smsservice. sendsms (Dist, change );
}  
// Other code goes here
}  
Public Class Smsservice {
Public   Static   Void Sendsms (useraccount user, bigdecimal change) {
Long phone=User. getphonenumber ();
Bigdecimal balance=User. getbalance ();
Send (phone, change, belance)
}  
Private   Static   Void Send (long phone, change, balance) {
 
}  
}  

In fact, from the perspective of User case, sending text message notifications is another use case, and it is the extend flow for transferring the use case. The method to use AOP should be as follows:

Public   Class Bankserviceex {< br> Public static void using Y (useraccount SRC, bigdecimal change) {< br> smsservice. sendsms (SRC, change);
}
// other code goes here
}  
Public Aspect bankserviceaspect {
Pointcut transfer (): Call ( Void Bankservice. Transfer (..));

After (useraccount SRC, useraccount Dist, bigdecimal change) Returning: Transfer () && ARGs (SRC, DIST, change) {
Bankserviceex. Y (SRC, change );
Bankserviceex. Policy (Dist, change );
}  
}  

in this way, the two use cases are separated and can be reused and tested independently. For example, the above text message notification cases can be reused in other situations, such as deposits, consumption, and bank dividends.
however, an object may be used in the Code section of two independent use cases, so part of the Code may be repeated in the two use cases. In terms of concept, we should not repeat it (we will not repeat it when using the old method), but from different use cases, it is worth repeating. We have considered using code generation to directly obtain the local variable, which can reduce the number of duplicates. However, this idea is wrong, not only for implementation difficulties, but more importantly, the separate text message sending case is bound to the transfer case, which depends on the transfer case and cannot be reused and tested independently.
in this way, objects, methods, and method parameters constitute a complete pointcut, which becomes a common entrance for slicing different use cases, it is equivalent to a placeholder. In this case, different use cases are required for the personnel to coordinate the portal.