11. Integration of the enterpriseframework framework and system services

The previous chapter details each layer in the javasiseframework framework, which is explained from the technical level, that is, we know how to create a controller or a business object, but what kind of controller or business object should be created during development?This chapter describes how to design reasonable controllers and Business Objects Based on System Business and customer needs..

 

Let's take a rough look at the analysis and design process for developing a system. After deciding to develop a system, you must first understand the system-related business content, based on your own knowledge of which type of system this should belong, it is similar to the sales, charging system or other systems, and you can also find out whether there is a similar business system on the Internet; these materials are worthy of reference and analysis before developing a system. In this way, you have a bottom point in your mind. How long does it take for your team to complete the process; you can complete the system analysis and design process with three axes,

First, draw business activity diagrams, use cases, and entities based on customer needs and business scenarios.

Secondly, based on experience or understanding, we designed the interface prototype and database structure.

Third, perform domain analysis on key system problems to obtain the domain object model.

In this way, the analysis and design of the system have been initially completed, and then the design is converted into code. Later, with the in-depth understanding of the business, the iteration will not be improved; in addition, I personally think that the use case diagram and domain model can help me better understand the business;

Let's look at the following issues that we often encounter when modifying the code,

1) modify oneLinkage features, Usually a string of code files, because the implementation code is scattered in multiple code files and not put in one file;

2) modifyKey System Problems, The code of multiple modules is often modified to completely solve the problem, because you have not encapsulated the code to solve this problem into a business object;

To solve these two problems, the distribution of our code must correspond to the actual business, so that we can quickly find the code to be modified and complete the modification at the minimum cost;

Use Cases: describes a logically complete functional process;

Domain Model: focus on analyzing the problem domain itself, explore important business domain concepts, and establish relationships between business domain concepts;

Let's change the use case and domain model to the vertical and horizontal perspectives to see the above two problems.A functional issue with strong linkage corresponds to a specific use case, and key system problems should be analyzed to obtain the domain object model; therefore, it is easy to control and implement the modification content in a use case or a domain object model. What is closely related to functional problems is the interface and controller, the business objects related to system-level issues are not the objectmodel business objects;

The relationship between controller and objectmodel is not included or included. The two are completely hierarchical. A controller can call multiple objects, and an object may be called by multiple controllers. Why is this relationship true, it is also easier to understand the code and maintain the consistency of the code reading. If there is no guiding ideology in the code design process, it is easy to confuse the code file, such: it is as difficult as naming multiple controls or variables if a class or method doesn't know where to put them;

In the process of using the framework in the project, we can look at the business analysis and design of the previous system:The Controller in the framework corresponds to the use cases in the business, and the objectmodel corresponds to the domain object model in the business; see

 

 

Since the content in this chapter does not have any specific code or examples, it is a metaphysical insight, so it is inevitable that there will be personal limitations, but it is all about experience and understanding in actual projects; these things personally think that it is more appropriate to explain some personal experiences for guiding thinking than to put out a complete set of theories; such as system analysts or system designers, it is impossible to become a system designer by learning two books of the ox, but by constantly training your experience in the project. A system designer gives you his methods and routines, you can become a system designer without learning it. In this case, it is better to talk about your personal experience and the feelings and feelings at every stage, which may be more likely to resonate with each other;

 

11. Integration of the enterpriseframework framework and system services