It is a theme that I am still exploring, but I will write it down because the policy has been set and the results have been obtained. For those who know it, it's "natural", so skip the article. The content is for young to mid-career. I hope that the discussion will further improve it.

Premise

Java application (C # is fine, if it's an object-oriented language)
For business systems regardless of BtoC or BtoB
Includes Web API etc. In short, Java batch etc. are not covered.
The project team's programming skills are not that high.
Imagine a team that has a large number of SEs (no longer coder) who have no skills even though the cost is full-fledged due to the harmful effects of multiple subcontractors.

Points to consider

I want to have a configuration that flexibly responds to changes in business (change / addition / deletion of requirements).
It will be continuously renovated in the future, but since there is a high possibility that the members will be replaced, readability is important.
I don't want to put in a very difficult theory because I can't expect the skills of project members. (I don't like DDD)

Is it such a place? The point is, "I want to write code that can be easily extended with simple code."

Conclusion

Write a brief conclusion. The class is divided vertically (procedurally) and horizontally (object-oriented) according to the role. It's not a big story, but how to divide Controller / Service / Repository in Spring Boot.

Concept 1: Premise that business is unique and mechanism is common

To put it simply, system development is often about getting the customer done. It's about efficiency and business creation. So, what is important at this time is ** When you look at various systems, what are the common parts and the parts that are not common ** </ font>? That's exactly what the headline says, and the customer's business itself is not the same. However, there is a high probability that the mechanism for achieving this is common.

Business is unique

For example, when considering the system of international remittance business of banks and ordering business of convenience stores, how much are the procedures in common? Isn't it 0? In this way, if the business type is different, the business will be completely different. Also, even in the same international remittance business, it will be different when a bank does it and when a securities company does it. Even among the same banks, UFJ and Sumitomo will be different (if the business is the same, it can be realized at low cost by installing the same system). In other words, basically the business part cannot be reused.

The mechanism is common

Even if the business system is completely different, the mechanism used in it is usually the same. What this means is that if you want to store data, use LDAP or SQL, and if you want to send a telegram, use HTTP or SOAP. In other words, you can see that the part of the mechanism such as storing in the DB or sending the request somewhere is common (or reused). If you focus on an industry, you may be in compliance with the standard. For example, it has been decided to use Swift Telegram for international remittance, so it seems that the mechanism is the same within the scope of international remittance business.

Concept 2: Accept duplicate code due to business

Occasionally, there are extremists who do not allow duplicate code at all and can call code that appears more than once as a method, but if you create a class or method with this idea (although it does not go so far ...) , It becomes impossible to separate according to the role, and a chaotic code is created in terms of both naming and function division. Also, even if it was beautifully divided by Extends etc. at first, there are cases where you want to change only a small part of the inherited class while continuing the repair (in the worst case, at the time of the next repair). ファイル名 Even if such a class is created first and divided beautifully, AbstractClass2 will be created and double inherited for processing that is only partially different in the next modification. It's the beginning of hell. I have seen up to quadruple inheritance.

In the past, it was said that unique codes were beautiful, but in cases where members with low skills are frequently replaced, complicated codes become a baggage. This is because the code cannot be understood or maintained. Then what should we do. Think separately for business and mechanism, implement the business part in each class, and standardize the mechanism part. Even if some duplicate code occurs, the business part is implemented individually. Even if most of them are common, it will be easier to repair. ファイル名 Method1 is implemented in the business class like this. The content of method1 may contain duplicate code, but let's accept the duplicate as a different business. Then, even if there is a requirement that you want to change only one of the tasks that were the same at the beginning, you can correct it by making the minimum changes. Method2 is placed in AbstractClass as a common mechanism.

It's getting a little longer, so let's continue with the next article.

How to think about class design (division) in a business system (1)