DDD - 商務規則

標籤：

1. Business rules are an important part of the business domain. They define data validation and other constraints that need to be applied on domain objects in specific business process scenarios. Business rules typically fall into the following categories:

• Data validation
• Data transformation
• Business decision-making
• Process routing (work-flow logic)

2. The context is very important in DDD world. Context specificity dictates（規定，命令，影響） the domain object collaboration as well as other run-time factors like what business rules to apply etc. Validation and other business rules are always processed in a specific business context. This means the same domain object, in a different business context, will have to process different set of business rules. For example, some attributes of a loan domain object (such as loan amount and interest rate) cannot be changed after the loan has been through the Underwriting step in the loan approval process. But the same attributes can be changed when the loan is just registered and locked for a specific interest rate.

注釋：可知，在不同業務上下文，會處理不同的商務規則。

3. Even though all the domain specific business rules should be encapsulated in the domain layer, some application designs put the rules in facade classes, which leads to domain classes becoming "anemic(貧血的)" in terms of(在...方面) business rules logic. This may be an acceptable solution in small size applications, but it is not recommended for mid-size to large enterprise applications that contain complex business rules. A better design option is to put the rules where they belong, inside the domain objects. If a business rule logic spans(跨越) two or more Entity objects, then it should become part of a Service class.

注釋：可知，商務邏輯應該放到相應的領域對象了，如果這個商務邏輯涉及多個實體，那就放到服務裡。

 

4. Also, if we are not diligent in the application, design business rules will end up being coded in the form of several switch statements in the code. And over time as the rules get more complex, developers don‘t take time to refactor the code to move "switch" statements into a more manageable design. Hardcoding the complex routing or decision-making rules logic in the classes leads to longer methods in the classes, code duplication, and ultimately a rigid （死板的）application design which will become a maintenance nightmare in the long run. A good design is to place all the rules (especially complex rules that change frequently as the business strategy changes) into a Rules engine (using a rules framework like JBoss Rules, OpenRules, or Mandarax) and invoke them from the domain classes.

 注釋：可知，就是把所有的商務邏輯放到一個業務引擎裡，然後通過領域類來調用。  "3"裡不是說這樣會造成商務邏輯的貧血嗎？

 

5. Validation rules are usually implemented in different languages like Javascript, XML, Java code, and other scripting languages. But due to the dynamic nature of business rules, scripting languages such as Ruby, Groovy, or Domain Specific Languages (DSL) are a better choice to define and manage these rules. Struts (Application layer), Spring (Service) and Hibernate (ORM) all have their own validation modules where we can apply the validation rules on the incoming or outgoing data objects. In some cases, validation rules can also be managed as Aspects (link AOP rules article here) that can be weaved into different layers (e.g. Service and Controller) of the application.

注釋： 驗證規則一般用指令碼來寫和管理，也可以通過AOP來管理。 例子呢？

 

6. It‘s important to keep in mind the unit testing aspect when writing the domain classes to manage business rules. Any changes in the rules logic should be easily unit testable in isolation.

注釋：時刻記得商務邏輯的可測試性。

 

7. The sample application includes a business rule set to validate the loan parameters are within the allowed product and rate specifications. The rules are defined in a scripting language (Groovy) and are applied on the loan data passed to FundingService object

 

Design:

1. From a design stand-point, the domain layer should have a well defined boundary to avoid the corruption of the layer from non-core domain layer concerns such as vendor-specific（特定供應商的） translations, data filtering, transformations, etc. Domain elements should be designed to hold the domain state and behavior correctly. Different domain elements are structured differently based on state and behavior. Table 2 below shows the domain elements and what they contain.

Domain Element	State/Behavior
Entity, Value Object, Aggregate	State and Behavior
Data Transfer Object	State only
Service, Repository	Behavior only

注釋：領域層需要定義一個號的邊界，這樣可以避免領域被其它非核心的領域所汙染。另外領域元素主要是基於 “狀態” 和 “行為”。

2. Entities, Value Objects, and Aggregates which contain both state (data) and behavior (operations), should have clearly defined state and behavior. At the same time, this behavior should not extend beyond the limits of the object‘s boundaries. Entities should do most of the work in the use case acting on their local state. But they shouldn‘t know about too many unrelated concepts.

 

DDD - 商務規則