DDD-Business Rules

1. Business rules is a important part of the business domain. They define data validation and other constraints, need to being applied on domain objects in specific business process s Cenarios. 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 (provision, order, influence) the domain object collaboration as well as other run-time factors like what busines s rules to apply etc. Validation and other business rules is always processed in a specific business context. This means the same domain object, in a different business context, would has to process different set of business rules. For example, some attributes of a loan domain object (such as loan amount and interest rate) cannot is changed after the L Oan have been through the underwriting step in the loan approval process. But the same attributes can was changed when the loan was just registered and locked for a specific interest rate.

Note: In different business contexts, different business rules are handled.

3. Even though all the domain specific business rules should is encapsulated in the domain layer, some application designs Put the rules in facade classes, which leads to domain classes becoming "anemic (anemic)" in terms of (on ... aspect) Business rules logic. This could be a acceptable solution in small size applications, but it's 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 (across) the objects, then the it should become part of a Service class.

Note: The business logic should be placed in the appropriate domain object, if the business logic involves multiple entities, then put into the service.

4. Also, if we is not diligent in the application, design business rules would end up being coded in the form of several s Witch 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 I Nto 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 (rigid) application design which would become a maintenance nightmare in the long run. A good design is-to-place all the rules (especially complex rules, the 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 cl Asses.

Note: It is known that all business logic is put into a business engine and then called by the domain class. "3" is not to say that this will cause business logic anemia?

5. Validation rules is usually implemented in different languages like Javascript, XML, Java code, and other scripting LA Nguages. But due to the dynamic nature of business rules, scripting languages such as Ruby, Groovy, or Domain specific languages (D SL) is a better choice to define and manage these rules. Struts (Application layer), Spring (Service) and Hibernate (ORM) all has 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 is managed as aspects (link AOP rules article here) that can is weaved into Diffe Rent layers (e.g. Service and Controller) of the application.

Note: Validation rules are generally written and managed with scripts, and can also be managed through AOP. What about the example?

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

Note: Always remember the testability of business logic.

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

Design:

1. From a design stand-point, the domain layer should has a well defined boundary to avoid the corruption of the layer FR Om non-core domain layer concerns such as vendor-specific (vendor-specific) translations, data filtering, transformations, etc. Domain elements should is designed to the domain state and behavior correctly. Different domain elements is 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

Note: The domain layer needs to define the boundary of a number, which avoids the domain being polluted by other non-core areas. In addition, the domain elements are mainly based on "state" and "behavior".

2. Entities, Value Objects, and aggregates which contain both state (data) and behavior (operations), should has 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 a most of the work in the "case" acting on their local state. But they shouldn ' t know about too many unrelated concepts.

DDD-Business Rules