A general-purpose architecture design principle driven by attribute core (abbreviation: Attribute schema principle)

The design principle of all-domain general architecture driven by attribute core

(Abbreviation: Attribute schema principle)

Contact information: 13547930387

Email:[email protected]

I. Personal statement

I, participated in the work also has more than 5 years, is an ordinary cannot in the ordinary programmer, has been using the company own product to carry on the development, therefore the technical comparison vegetable, this design completely is according to own naïve idea and the design, if has unreasonable or very funny place, please pat, sincerely hoped that everybody can put forward the valuable opinion;

According to this design principle I have also made a simple (demo) architecture to support and verify the feasibility of this theory, due to the technical foundation is not very good, there are unreasonable please understand, but also hope you can be more excellent design solutions to share to everyone, sincerely thank you!

Second, the original design

I am an ordinary software engineer, in the actual work of the development of real experience, the current system is basically targeted for specific areas of development, but no matter what the field of demand is constantly evolving, especially the operation and maintenance of online systems, demand changes very quickly.

Of course, there are also many architects who have designed very powerful architectures that are highly scalable and versatile, but are designed for specific areas of architecture, so the benefits described earlier are more scalable and universal (code-level) for new requirements at development time, and as systems are being modified more and more, Maintenance personnel also changed batch after batch, the system becomes more and more chaotic, the maintenance cost increases rapidly, facing the new demand is the inadequacy; for a long time, the life of this system is also the end, this is what the industry often say the so-called software life cycle-of course, excellent architecture design and project management can largely avoid appeal issues, But only a few.

At present, most software companies will be involved in various industries of software development, for different industries will be new design architecture, the development of a new set of systems (such as pharmaceutical systems, Enterprise Portal, news portal, advertising system, mall system, etc.), if there is a set of requirements to meet the needs of the general architecture, on this basis to carry out two development, That is not to save a lot of cost, shorten the development cycle, this is the original intention of this design. Of course, the ideal is very naïve, concrete also see how the effect.

Iii. origin of Ideas

A long time ago, a sudden burst of inspiration, the emergence of two very special theme sites, initially planning to use a three-way system to build a website, then began to find the right system in the Internet, and struggled to find a period, but has not been found to fit the two types of theme of the site system; free, paid, All did not find satisfaction, helpless can only do their own hands-on; But the problem came, relying on my own power to complete the development of two systems, it is really a bit difficult, even if completed and do not know what year the horse month, I want to lazy to take a shortcut, I hope to do a system to meet the two theme site; Two types of theme site features and content is very different, if you want to do a system to meet the two different big theme sites, if still in accordance with the existing way to develop, the system will certainly be very bloated, because it is an online system, the subsequent expansion of new functions is also a problem, so to achieve this goal, Only from another angle to analyze and build the system architecture, then I began to find their common journey.

In the process of analysis, I also combined with the current work of some requirements and development experience, the actual work of the development of the system is also on-line operation and maintenance system, the demand is constantly, in the collation of previous requirements, in fact, all the requirements of the content is around the main function in the modification (such as: Add new fields for the primary function, Vaguely feel the similarities and the law, that is what it, into the thinking ...

In the promotion of these two factors, I began to explore how to solve my doubts and puzzles.

Let's start by throwing a few questions:

1, I think from the perspective of class philosophy, we work overtime, night-long to do so many system site purpose and purpose is what?

2. What is the relationship between the user and the system website?

3. Are there any similarities in the performance of these systems?

Definition of "user": Refers to the external operators and users of the system, and the logical user (account) defined in the system for mapping the former. Description: For the system operator, not only people, but also the system, scheduling process and so on.

Iv. current areas of the system collation classification

Then use a few more representative of the site system analysis

1, the news portal type website system, this kind of website should be the internet most common, although in the display form multi-style diverse, but the essence still is same-provide the reading content and the information entry;

2, Shopping web site system, the content of this site has become a product information, each product will be derived from a lot of attribute information, operating restrictions on more;

3, Backstage management type website system, this kind of system is the front-end system data and attribute management (increase and deletion check), as well as various permission configuration of add and delete changes;

4, the Resources category, Forum category, blog category, Enterprise Yellow Pages category as well as the portals of various industries, have a common is to provide content;

5, no interface process system.

It is not difficult to find out from the above classification of the system websites of various fields, they all have a lot of similarities.

1, data content: The website is to provide the data content for the browser to browse, regardless of what type of website system, is to provide content display, management system is more to reflect the data relationship-but it is still content display AH.

2, show the form: this actually HTML page label has been sorted for us, such as text box, Rich text box, drop-down box, multi-box, radio box, list, what else, no?

3, Operation: Browse, edit, upload, download, drag.

4, browsing the site must be an identity role to operate---undefined (not logged) of ordinary users, defined (login) the specific user role to access the site system.

Five, System structure analysis

However, with the development of the Internet, business needs become more and more complex, in order to meet these requirements, the system is more complex. Multiple modules, complex classification, a variety of relationships and permissions staggered.

The following is a simple description of the system's composition:

I think: when we deal with these complex needs and design more complex systems, but the system is the original intention and the essence of the neglect, that is, the system is to provide data content to users to browse and view, the user from the system to obtain the required information----otherwise what purpose?

So users are most concerned about and most of the data content in the system, other content related to the classification, parameters, attributes and other data, the user does not care, or just through them to obtain their own more needed content.

So the derivative content associated with the data content is just for better access to the data, no matter how they change, the user is ultimately concerned about the content, as for the others do not care.

The evolution of website structure under the new theory

We simplify the process of system processing, such as:

From our very clear that the user is more concerned about the data, the middle of the user does not care, so we first put the redundant content aside, a system has become,

But the extra part is not going to be cut off directly, so let's put it in a category.----property, the user obtains the corresponding content to be bridged by the properties of these columns;

But we do not simply provide content to the user to browse, which is attached to the conditions, such as content is categorized, content is set to read and operate restrictions, only specific users can browse and operate, etc.;

So we can't have a simple association of attributes, but there are a lot of limitations, so that a particular user can see the specific content, then we need to establish rules, so that properties can provide the appropriate content according to user characteristics.

Here are three questions to answer: Provide content for user action (reading, typing, selection, etc.).

Principles of attribute architecture

With the above analysis, we can classify the system in a completely new way:

1, all the contents of the system are classified into a class (see, logical use)----content attributes;

2. In this way, they all belong to the same class, then we define a category name----attribute for such classification;

3, but the system all the content is bound together, the data is very much, in order to better manage, put them into a container to manage---attribute pool;

4, there are various relationships between attributes, then we will record their relationship;

5. Then define various rules to remove the content attributes from the pool for use by the user.

Therefore, the final architectural principle:

Rationale: Define all the contents of the system as attributes (data content and related attributes), configure their relationships, and configure these attributes with user-defined permissions, thus establishing an operational relationship between the user and the data content.

This design concept is also in line with the present design idea, namely the function independence, the data centralization design idea.

At this point, my "attribute-driven Universal Architecture Design principle" is complete.

Eight, based on the principle of Deduction design (Demo)

Simple flowchart:

8.1, the following definition of the entire attribute pool

8.2. About attribute relationship configuration and permission configuration

8.3. Flowchart

8.4. System Framework

8.5. Frame flowchart

8.7, Attribute Pool Property Management method

Description

1, all the attributes are displayed in a tree-shaped menu;

2, and through the various categories of attributes to search;

3, Attribute pool properties are Free State, has not been used by the system;

4, attributes only the defined attribute group composition can be used by the current system;

5. Relationships can be viewed with each other between attributes and attribute groups

8.8. Attribute Relationship Configuration

Description

1, any attribute can be used as the root attribute of care configuration;

2, if a property has been configured with his subordinate relationship properties, then the other attributes associated with the secondary attribute will not need to continue to associate--otherwise endless;

3, the attribute and the attribute can have the relation algorithm to control the mutual data change;

4, the relationship between attributes and the inclusion relationship directly control the temporal and business logic of the page data processing;

5, the attribute can define the base---initial value;

6. The property expanded here is the attribute of the attribute group-and the attribute that has been used by this system;

7, the relationship algorithm is divided into simple algorithm, complex algorithm, combination algorithm, custom algorithm;

8.9. Permission Configuration

Description

1, the properties shown here are also used by the system properties;

2, each property can configure permissions and level permissions, but if not configured will use the parent permission configuration;

3, the configuration algorithm is divided into simple algorithm, complex algorithm, combination algorithm, custom algorithm;

Ix. Future Prospects

Architecture principles Core Modules: attribute pool management, attribute relationship configuration management, attribute permissions configuration Management

Extended Modules: Attribute Cache Center Management, interactive information management, Calibration center management, basic function management, message management, etc.

If this architecture principle has been recognized by everyone, but also has a person committed to the principle of the design of the corresponding architecture products, each module has a wealth of product support, then the development of the future is more simple, of course, people need to define a specification agreement between these modules, we all follow these protocol development, Can be scattered from different companies of the module products at random splicing together to complete a complete system development, too perfect.

Such a picture is configured for the attribute relationship, which can be graphically defined and configured directly later:

The same is true for other modules.

Ten, the following is based on the design of the demo set up according to the new requirements of the contingency process

10.1. Add attributes and related business logic to the original function

10.2, for the system to add a separate function module

This!

A general-purpose architecture design principle driven by attribute core (abbreviation: Attribute schema principle)