My view on the architecture of Java project

I've seen a lot of things on the internet, and it's really hard to find something about Java software Architecture, but the architecture of software development is basically the same. So, I looked up a lot of other languages on the internet about software architecture. And here's how you think about software architecture, especially in Java project architecture. That's not necessarily true, but that's what I've summed up over the years.

　1. Try not to consider the reuse outside the project

Many people think that it is best to improve the reusability of the software, however, the actual situation of each project will be different, in the design of a project in a module, methods, too much consideration of the reuse outside the project, will inevitably increase the complexity of the project, increase the cost of development time. It may be said that this will reduce the cost of the next project, what is the next project? What are the requirements? What are the factors affecting all aspects? Who would know all this at the present moment. If you really want to reuse, you should be at the end of the project after the reusable part of the extraction, modified, optimized as the enterprise reusable assets, rather than the current project wishful thinking. Consider the reusability of the project, this is a lot of software developers just work often make mistakes, often consider the more, instead of the software can not achieve the design effect, complete the basic function or code logic too much, the program function is not perfect and so on.

　　2. Regular inspection of project structure

The project architecture is usually something that has been identified before the project implementation begins, and is a general design. However, in this case, the understanding of the project requirements, complexity estimates are still in an initial stage. If you cannot improve the architecture as you understand the project during the project development process, the members of the project will have to develop the project according to the wrong architecture. Therefore, it is necessary to check the architecture of the project frequently, and to reconstruct it.

3. Refactoring

Some people say, have written so much, and then revise is not a waste of time. He may not have thought that an afternoon of refactoring would speed up the development of the next few months, and that the time saved was unimaginable. Furthermore, by refactoring, more simple methods can often be thought of in place of existing implementations, and such experiences can also simplify the development of other modules.

4. Avoid excessive integration, so that each module only do their own thing

A common example of OA development is that in a business system there is usually a lot of approval, and many people will suddenly think of the approval into a common module. It's no problem, but the usual problem is, too many people will be approved after the end of the business process also put into the approval module business logic, in fact, those are the business module of their own things, approval should only be completed approval can be, as for the approval after the completion of the work of the module to deal with their own.

　5. Avoid excessive flexibility

Design and code are not the more flexible the better. A common example is that when using generics, you can make a class or method manipulate different objects, however, in JAVA's commonly used three-tier architecture, if a series of classes are intended to operate on a particular entity, it is not necessary to specify the generics, and then specify the use of specific entity classes when used. This is quite the feeling of the lily.

6. Reduce the icing on the cake

Page no refresh, cooler display, and so on, for the business system is the icing on the cake, if because of these and so the business interface is very complex, to the business process brings a series of problems, the extreme case is the business process can not continue, and then the beautiful interface is useless. A piece of advice, consider others only if you are sure that your business is handled correctly. One prerequisite for this is the necessary communication with the user. In other words, the Java implementation of the project, the focus is on the business processing, only a good implementation of business processing, to consider the aesthetic interface and the user's visual sense.

7. Appropriate split

This is similar to 4. Try to reduce the complexity of each module, so that the mental work into manual labor. A common example is the ability to add, modify, delete, and view a form. However, the first three operations typically operate only on a single function point, a specific state, or someone with specific permissions (perhaps only in a single interface in the system). The viewing operation is distributed across all corners of the project, and if you put all four of these actions in the same interface, although the number of interfaces can be reduced, but the increase is the complexity of the interface, to the various states, conditions must be judged to do the interface elements of read-only settings, the increase in complexity is a number of degrees, And if you split the view, the workload will be linear, even if you want to do 10 viewing interface, it is more easy to deal with than the complexity of the 10*10, and can also be modular.

　8. Maintain good communication with customers

Many people do not pay attention to maintain communication with customers, many architects believe that only in the project requirements of the need to communicate and communicate with customers, this is a bad habit, because the customer requirements will change over time, only regular and customers to maintain good communication, in the first time to understand the needs of customers change To adjust their own project architecture program, in the shortest possible time to meet customer needs.

9. Relationship between project architecture and database architecture

Many people believe that the project in the development process, is not the need for a database, as long as in memory to achieve it. I personally think that this is a very bad development habits. The database is based on the specific needs of the project. However, a project in the framework of the architecture process completely regardless of the database architecture, it is likely to make the project implementation of things in the database is difficult to record or database design is very cumbersome, virtually increased the difficulty of project development. And, in the project development process does not consider the database, may make the project after the affiliation database, some business logic cannot realize, the data loss and so on.

Of course, many people's architectural style is different, there will be different architectural insights, my opinion is not necessarily correct. I hope you can learn something from my things, and I hope you can exchange a lot of views on the structure