CHAPTER 4- Refactoring Toward Deeper Insight
Continuous Refactoring:- Refactoring is the way toward upgrading the code to improve it without changing application context.
Approaches to do Code Refracting
Sometimes there is a possibility of new knowledge into the domain, something which gets to be clearer, or a relationship between two components is found. In that cases Refactoring is essesntial in some portion of Domain Modeling.
One of the principal things to perform in Domain Modeling is to read the business specifications and search for nouns and verbs. The nouns are changed over to classes, while the verbs get to be methods. Refactoring is done in little stages and the outcome is additionally a progression of little enhancements.
We begin with a Shallow model, refine it, include new concepts and performs abstraction. At that point the Model plan is Refactored. This is the time we achieves the leap forward which includes an large measure of refracting. We ought to make certain ideas unequivocal when required. We ought to make classes and connections for them also.
Try to check whether there is a missing idea. On the off chance that one is discovered, make it explicit. Refactor the outline to make it less complex and suppler.
There are different ideas which are exceptionally helpful when made explicit, for example, Constraint, Process and Specification.
Constraint:
A Constraint is a basic approach to express an invariant. Whatever happens to the question information, the invariant is regarded and not changed at any stage.
Specification:
The last technique to make ideas express that we are tending to here is Specification. Just stated, a Specification is utilized to test an object to see whether it fulfils a specific criteria.
The domain layer contains business rules which are connected to Entities and Value Objects. Example: A test performed on a Customer object to check whether it is qualified for a specific credit. We may be enticed to move the entire rule to the application level, since it appears that it extends beyond the domain level. The rule should be encapsulated into an object of its own, which becomes the Specification of the Customer.
Specification is utilized to test objects to check whether they satisfy some need, or if they are prepared for some reason. Often a single Specification checks if a simple rule is satisfied, and then a number of such specifications are combined into a composite one expressing the complex rule.
Important Chapters in Domain Driven Design
