Gradually improve legacy code
This text is the article on the 13th day of "Tech Fun Advent Calendar 2017".
It's about the approach and impression of gradually introducing DDD while refactoring an unordered project.
Initial state of participating in a project
It is a Spring Boot project with Java8, but the code was as follows.
--There are many copy and paste codes. --There is no unit test. --The "Model" is passed from the Controller to the Service, and the Service knows which View to display. --DB access is written in Service using the automatically generated mapper of MyBatis. --Service is a so-called transaction script that supports screens and functions.
Aside from the fact that the Controller isn't working, I think it's quite possible that the Service has become a transaction script.
What's wrong?
Weak to change. That's all. When business rules are changed, changes occur across the board, and any omissions are naturally bugs. The test is also difficult.
First approach
Before DDD, I think it's important to talk with team members and be aware of the problem. Divide the layer appropriately and write the test.
Separate layers
| component | Responsibilities |
|---|---|
| Controller | Handles requests and responses. |
| Service | Write business logic. Don't bring your web interests here. Don't do persistence here either. |
| Repository | Make it persistent. Query throwing is also abstracted here and treated as a collection in the domain layer. Separate interface and implementation. |
From here, I will take it to the three-layer + domain model.
Write a test
In consideration of the schedule, I actually compromised and prioritized the critical ones, and wrote the unit test focusing on the minimum necessary functions.
Introduce DDD step by step
What kind of code is vulnerable to change?
In a procedural design that separates data classes and functional classes, duplicate business logic is written everywhere. As a result, you don't know where to change.
On the contrary, what kind of code is resistant to change?
It consists of a group of objects (domain model) in which data and business logic are organized. By separating them into units of interest, you can quickly see where to change.
Quote: Principles of system design useful in the field ~ Object-oriented practical techniques that make changes easy and safe Interest in three layers + domain model Separate things in an easy-to-understand manner
Extract the domain model from View and Service
Basically, I think it is better to use the term used in business as the class name. It's important to always think about good class and method names, and when you stop thinking, legacy coding goes on. In domain model-driven design, I feel that DDD can be introduced immediately because it is possible to take an approach to make the whole step by step by focusing on the parts and combining individual parts.
Reference book
DDD Recently, it is recommended to start from around Principles of system design useful in the field ~ Object-oriented practical techniques that make changes easy and safe. ..
You need to sit down and read, but the following is also a must read. ・ Eric Evans's domain-driven design ・ Practical Domain Driven Design