Modeling your Business

This is not a fresh topic, but recently I have some thoughts about maintaining a project that was left behind by a colleague. In fact, I have not done a specific business for a long time. A long time is mainly responsible for the development of infrastructure and business tools, so I do things, often do not need and specific business dealings, in fact, this is very difficult, the key is that I am not the designer, the designer is the other full-time designers, he has a high degree, working hours also long, but unfortunately, He doesn't have much experience in the architecture and design of web systems, so things are really hard to do.

And now take over this project is a very pure business system, not too many independent design, using the standard Java EE, from the technical above is understandable. But what's worse is that the entire system doesn't model the business, but instead distributes the business across a multitude of restful APIs and SQL statements. I think this is actually a kind of maintenance disaster, too many APIs to divide the business fragmented, do not know what the use of these APIs. The directory structure of the system is divided according to the technology, this division method I have to spit, the business is hidden under meaningless technical terms, greatly increased the difficulty of understanding people.

So I think the business should be modeled, at least in the program, to see the business context, not a bunch of technical terms. And it's easier to make people aware of the boundaries between the various business modules, and will not make the so-called DAO What service or anything too bloated. It is easy to choose a technical term to name the folder in the system, I think mainly because the business naming is difficult, because:

1. Business is always evolving and changing

2. The business has no clear boundaries

3. Business is always implicated in each other

4. No matter how complex the business is, the technology that is implemented is always the same.

It seems that we are organizing our code according to technology, and there is nothing wrong with it.

So there are two cases of organizing code:

1. Technology-"Business

2. Business-"Technology

The first is most common, and people who use spring are generally the same style. You'll find that in its code structure, top-level folder names are technical nouns, what DAO, what service and so on. A business-related code tends to be scattered across the classes in these folders. The consequence of this is that you never know where the business is, you can't see it, you can't touch it. As the business changes, the contents of these folders are changing, and ultimately it is impossible to abstract a model for reuse. The reusability of the code is: 0.

There's a lot of commented-out code in this code, and a variety of remedial measures. The code is expanding at an alarming rate, and a huge tar pit has already appeared in the distance. Spit it out: a long time ago, when we learned the design method of UML, we need to model the business, and then EJB, this also need to model the business. Then there was the popularity of web systems, and the advent of spring. But I do not know which genius started the program and no longer see the business model. Business is impossible to disappear, an important reason for not modeling is that these businesses may be very simple, but it cannot always be simple. Especially if you want to accumulate or want to reuse. Technology-centric projects are very difficult to reuse because you need to carefully dismantle them and do the same thing again.

The second way, I feel better. It has a very important advantage, is that it can be reused. And, to some extent, abstract business does not rely on specific technical implementations, which is good for business optimization. In addition, for most companies, the business is the real value of things, technology is not the core, technology is only a carrier of value, value embodied in the business. But it has one of the biggest drawbacks, which is difficult. It is very difficult to make a good model when it is very demanding to the realization person. That's it. Not to be able to achieve through reading, a degree, need a lot of practice, and a higher talent.

Modeling your Business