Technical Discussion Summary: customization and caching

Recently, the gix4 project needs to be customized. In the next sprint, the customer also needs to significantly improve the product performance. In view of the existing problems, developers decided to hold a series of technical seminars.
I have summarized the current and possible problems:
Customization:
Entity-class Customization
Each customer needs the same product and requires the entity class to beProgramOn Different. This requires that the domain model be customizable.
Interface Customization
The interface needs to be customized because of different requirements. This is a general requirement.
Performance:
Entity Optimization
Currently, the system uses Entity classes based on the csla object model. Because csla-managed attributes are used, the performance is poor. At the same time, because an aggregation class is often aggregated by multiple multi-layer entity classes, the base class of csla is being debugged during debugging, the base class uses the same pattern for all object classes, and uses recursion and inheritance to structure object classes.CodeDifficult to debug, often confusing.
Cache Seeding
To improve the performance of distributed systems, the most direct and easy-to-use method is to cache commonly used and infrequently changed objects, reducing network transmission and reducing database access times.

20100826
Today, we talked with Zhou Ge, du Qiang, and Zhi Ge about the system's custom solution. It lasted for about two hours, with little content and little gains, but it was very important. There are two main points:
First, the idea, architecture, and roadmap of gix4 (including openexpressapp) are clearer.
I think the idea of the product gix4 architecture can be explained as follows: Product Line architecture methods specific to the construction field.

Different from projects, a product is developed for the entire construction industry. Its versatility needs to be considered and must be able to meet the customization needs of enterprises. The entire product line development involves three types of customers, which are divided according to the 721 principle. These three types of customers are:
Category 1 users: 70%; the functional requirements of these customers fully comply with the industry's habits. They represent the general situation of the industry. These requirements must be included in the product.
Level 2 users: 20%; these customers are generally divided into several categories; the requirements of the same category of customers are often the same, and the requirements of non-class customers are often different; these requirements are also included in the product, the product requires certain policies to be customized for various users.
Personalized users: 10%; these customers' functional requirements often come from their own habits and cannot be used by other peers. Such requirements will not be included in the product, but as a platform product, it should have the ability to expand the features customized for these users.

The software architecture is driven by fields. Therefore, the domain model in the main code must represent the overall needs of the industry. At the same time, it is necessary to express the situation of second-class users, which may require multiple small branch models. Personalized user needs need to be expanded on the basis of the backbone model. (Inheritance is mainly used in class design, and the modeling environment will be supported in the near future, and model extension also needs to be supported .)

2. Avoid ambiguity during design.
The discussion of design is an episode caused by a specific problem, as follows:
In the original product design, there was such an aggregation relationship: Project-> contract-> Budget; but now you need to support: Project-> Budget. These two requirements are proposed by two irrelevant customers. They cannot exist at the same time.
I initially advocated the aggregation of budgetparent-> budget, and the project and contract are inherited from budgetparent. The reason for putting forward this solution is that I started to push back the field requirements from the customer's needs. I think in the customer's superficial consciousness, a certain item is organized (budgetparent) on top of the budget ). But later I learned that this inference is one-sided, and the industry does not have such cognition. Therefore, from the perspective of the field, this design is not true.
For the solution I proposed, Zhou Ge proposed to avoid design with ambiguity. If it is only a project and a contract, you do not need to introduce a "budgetparent" class or interface unless necessary. This will not only increase the complexity of the program, but more importantly, it will make the program vague. people looking at the program cannot see the field requirements at a glance from the design of the class. Later I thought, if this is true and there is no need, it would be helpful to use specific classes. Do not complicate the field because of program considerations.
It was concluded that it was necessary to confirm with the field experts again before they could know whether a budget could be organized by the project and contract at the same time. If yes, the budget class should own references to the project and contract. If not, you may need to design two different budget sub-classes. Indeed, no matter which one is selected, the relationship between budget, project, and contract can be clearly expressed. :)