[JAVA] 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

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