Domain architecture in CMF / CMS systems
Virtually any information system is characterized by the presence of a data storage and operation system. Take, for example, ordinary websites. To create them, we usually use any ready-made systems (frameworks or ready-made CMS), in which some kind of concept for working with data, an established subject area has already been laid down. Usually, if a developer wants to add a news section on a website, he adds a component, an information block, a template, etc. in the CMS interface. The essence of all these structures is the same - to create an entity in the database for storage (or some other storage). As a result, there is a relational database and, often, some object-oriented body kit that implements a bundle of object-attributes-properties-methods - the subject area is implemented.
Below we will talk about one of the variants of the domain architecture. The article is based on the experience of the company ADV , which uses similar methods in the development of web projects. The complexity of the material presented allows us to understand it not only for software developers, but also for webmasters who need to periodically refine existing web projects by adding new data to them.
The simplest systems allow you to only organize a repository, to which the developer subsequently addresses and does all the necessary work of processing the data himself. In such a repository there is only an object, fields and data. In more advanced systems, connections appear between objects. The next level of development is the interaction of objects (triggers, methods, etc.), as well as the presence of a software subsystem that removes some of the data processing concerns from the developer.
Imagine the perfect application in which everything is built on a well-established subject area. Its architect (usually, a specialist in any storage systems) knows the future of the application in advance and creates a repository for it according to the principle that it covers 2 of the 3 levels of application development: the storage level and the level of algorithms. Further creation of the functionality by the web developer is only a matter of a business task (display all blog posts, select all comments on the current blog post, etc.).
')
And the developer is not very important to know exactly how the data storage structure is organized at the SQL level (the data storage structure is implemented as data itself, implemented with standard DBMS tools, or mixed). It operates on object attribute concepts. The subject area in this case can be represented as a graph. In addition to the standard characteristics of the object (attributes (information), relationships), the terminological field has:
The object model should allow to choose the set A by the known parameters B: A (B). Here are some practical examples:
What is the peculiarity of this model? The developer does not need to know how the User and Gift objects are related. It is enough for him to describe the required business logic in some form (API provided by the system), and the server itself will build the necessary connections and produce the desired result.
For the architect of the database, the system represents a mechanism that allows you to describe all objects, relationships, etc. Ideally, the system can also provide an interface in which the architect can visually see the structure of the data warehouse created by him.
To implement this model, a so-called object server is created. It is an independent application that has some interfaces for interacting with other applications. The object server knows about its components and determines for itself what information was requested from it. The client application, in which the developer describes his database requests, does not know the structure of the database, but has mechanisms that allow you to request the required information from the object server.
Consider an example, our subject area is depicted as a graph.
The graph describes the situation with cellular communication: operator - region - tariff - sim card (number) - contract - telephone - brand - person - where it is registered. Request example:
The client application sends the parameters of the “Man” and “Brand” objects to the object server, which should build a link for them and provide a list of the regions in which such people live. As we can see from the graph, there are several ways to bypass it in order to reveal the connections. For the calculation, a tree is constructed sequentially, the root of which is the desired object (Region), and the branches are all sequentially related objects. The construction takes place in several iterations from the desired object deep into the graph. In our example of a tree of such levels 4. In the tree, each object participates only once. After building on the necessary nodes, the parameters set by the developer are marked, the extra nodes are cut off. In the example of region sampling, the “Contract-Operator” branch is not required, so it is not taken into account. And according to the exhibited “Brand” and “Man”, the object server will definitely be able to determine the Region.
So, we figured out how the possible paths between objects are built to calculate the function A (B). It remains to understand which route is chosen by the object server. Everything is very simple: the route is chosen the shortest based on the weights of the objects participating in it. It is logical that an independent object has the greatest weight, equal to 1. The bundle object has a weight of 1/2. Other storage entities also have similar weights.
When designing systems, especially those that will later be developed gradually, increasing the functionality, there is always a danger of complication and littering of the base. In the subject area, intermediate links are very often modified, but there is a basic terminological area that does not change over time. Bundles and auxiliary objects are changing. When adding a new module, it is most effective to build it on the basis of the same physical data storage, but as basic objects common to the entire system (for example, user, city, etc.), use them not, but aliases objects . This is an independent object in the object server, completely copying the structure and data of its parent. However, in the structure of the graph it is independent vertices.
In our example, we did not use aliases. But there is a so-called ring that provokes the object server to build connections along several routes at once. For example, if the developer wants to execute the Region request (Human Age> 20), then the object server will have to go along two routes at once, one of which is short and the second is longer.
This, in turn, increases the time and resources to perform operations. The DBA should avoid ring formation as much as possible during the design process. In this, it can be helped by objects-aliases or a special parameter that marks objects that are finite and do not allow building through connections through themselves. The architecture also provides an object bundles that help in eliminating the many-to-many links.
Of course, the object server algorithms are not always able to most effectively build connections, and sometimes they are not built at all in the way the architect intended. To force the inclusion or exclusion of objects from the link, there are also special parameters. In addition, it is often necessary not only to indicate the presence of an object in the relationship tree, but to describe in more depth the very essence of the relationship. In this case, a tool comes to the rescue, allowing the algorithm of constructing the tree to enter special conditions on the DBMS syntax.
Depending on the type of architecture, it is possible that the storage and presentation of data is different. Those. there are virtual objects that are not an exact projection of some objects in the database, they may not have their own table in the database at all. This is somewhat broader than just alias objects. For example, a calculated object, an analogue of a VIEW entity in a DBMS that contains fields whose contents are dynamically calculated based on the fields of other objects in the same repository.
The purpose of the article was to show that when developing a control system it is often better to think not only about which tables will be in the database and how they are related, but also about what tools are offered to work with them. As with all this, a web application developer can save time. Such an approach allows building large, well-scalable data structures with individual settings for each object independently of others. And it's not just how to wrap the data beautifully, but also how to simplify the appeal to them.
The described scheme has been implemented in one closed Mozart framework used by ADV for more than one year to develop web projects. In general, the tool fully justifies its existence, because it is precisely during the creation of web sites that a significant routine part is simplified. In addition, it is easy enough for a new person to grasp the essence and quickly start learning to directly develop projects.
In the near future, Mozart is likely to be published open-source under one of the free licenses.
Below we will talk about one of the variants of the domain architecture. The article is based on the experience of the company ADV , which uses similar methods in the development of web projects. The complexity of the material presented allows us to understand it not only for software developers, but also for webmasters who need to periodically refine existing web projects by adding new data to them.
The simplest systems allow you to only organize a repository, to which the developer subsequently addresses and does all the necessary work of processing the data himself. In such a repository there is only an object, fields and data. In more advanced systems, connections appear between objects. The next level of development is the interaction of objects (triggers, methods, etc.), as well as the presence of a software subsystem that removes some of the data processing concerns from the developer.
Imagine the perfect application in which everything is built on a well-established subject area. Its architect (usually, a specialist in any storage systems) knows the future of the application in advance and creates a repository for it according to the principle that it covers 2 of the 3 levels of application development: the storage level and the level of algorithms. Further creation of the functionality by the web developer is only a matter of a business task (display all blog posts, select all comments on the current blog post, etc.).
')
And the developer is not very important to know exactly how the data storage structure is organized at the SQL level (the data storage structure is implemented as data itself, implemented with standard DBMS tools, or mixed). It operates on object attribute concepts. The subject area in this case can be represented as a graph. In addition to the standard characteristics of the object (attributes (information), relationships), the terminological field has:
- It is possible to organize not only communications, but also interactions (triggers);
- graph routes (closed, unlocked, often changing);
- rejecting the need to know what SQL tables actually look like;
- methods (add a user, sending a letter by mail, and add something to another object).
Object model
The object model should allow to choose the set A by the known parameters B: A (B). Here are some practical examples:
- list of users whose age is> 20: user (user.age> 20);
- gift list for users with age over 20: gifts (user.age> 20).
What is the peculiarity of this model? The developer does not need to know how the User and Gift objects are related. It is enough for him to describe the required business logic in some form (API provided by the system), and the server itself will build the necessary connections and produce the desired result.
For the architect of the database, the system represents a mechanism that allows you to describe all objects, relationships, etc. Ideally, the system can also provide an interface in which the architect can visually see the structure of the data warehouse created by him.
To implement this model, a so-called object server is created. It is an independent application that has some interfaces for interacting with other applications. The object server knows about its components and determines for itself what information was requested from it. The client application, in which the developer describes his database requests, does not know the structure of the database, but has mechanisms that allow you to request the required information from the object server.
Consider an example, our subject area is depicted as a graph.
The graph describes the situation with cellular communication: operator - region - tariff - sim card (number) - contract - telephone - brand - person - where it is registered. Request example:
- region (man. age> 20, brand = Nokia);
- region (man. age> 20).
Connections
The client application sends the parameters of the “Man” and “Brand” objects to the object server, which should build a link for them and provide a list of the regions in which such people live. As we can see from the graph, there are several ways to bypass it in order to reveal the connections. For the calculation, a tree is constructed sequentially, the root of which is the desired object (Region), and the branches are all sequentially related objects. The construction takes place in several iterations from the desired object deep into the graph. In our example of a tree of such levels 4. In the tree, each object participates only once. After building on the necessary nodes, the parameters set by the developer are marked, the extra nodes are cut off. In the example of region sampling, the “Contract-Operator” branch is not required, so it is not taken into account. And according to the exhibited “Brand” and “Man”, the object server will definitely be able to determine the Region.
So, we figured out how the possible paths between objects are built to calculate the function A (B). It remains to understand which route is chosen by the object server. Everything is very simple: the route is chosen the shortest based on the weights of the objects participating in it. It is logical that an independent object has the greatest weight, equal to 1. The bundle object has a weight of 1/2. Other storage entities also have similar weights.
Types of objects
When designing systems, especially those that will later be developed gradually, increasing the functionality, there is always a danger of complication and littering of the base. In the subject area, intermediate links are very often modified, but there is a basic terminological area that does not change over time. Bundles and auxiliary objects are changing. When adding a new module, it is most effective to build it on the basis of the same physical data storage, but as basic objects common to the entire system (for example, user, city, etc.), use them not, but aliases objects . This is an independent object in the object server, completely copying the structure and data of its parent. However, in the structure of the graph it is independent vertices.
In our example, we did not use aliases. But there is a so-called ring that provokes the object server to build connections along several routes at once. For example, if the developer wants to execute the Region request (Human Age> 20), then the object server will have to go along two routes at once, one of which is short and the second is longer.
This, in turn, increases the time and resources to perform operations. The DBA should avoid ring formation as much as possible during the design process. In this, it can be helped by objects-aliases or a special parameter that marks objects that are finite and do not allow building through connections through themselves. The architecture also provides an object bundles that help in eliminating the many-to-many links.
Of course, the object server algorithms are not always able to most effectively build connections, and sometimes they are not built at all in the way the architect intended. To force the inclusion or exclusion of objects from the link, there are also special parameters. In addition, it is often necessary not only to indicate the presence of an object in the relationship tree, but to describe in more depth the very essence of the relationship. In this case, a tool comes to the rescue, allowing the algorithm of constructing the tree to enter special conditions on the DBMS syntax.
Depending on the type of architecture, it is possible that the storage and presentation of data is different. Those. there are virtual objects that are not an exact projection of some objects in the database, they may not have their own table in the database at all. This is somewhat broader than just alias objects. For example, a calculated object, an analogue of a VIEW entity in a DBMS that contains fields whose contents are dynamically calculated based on the fields of other objects in the same repository.
findings
The purpose of the article was to show that when developing a control system it is often better to think not only about which tables will be in the database and how they are related, but also about what tools are offered to work with them. As with all this, a web application developer can save time. Such an approach allows building large, well-scalable data structures with individual settings for each object independently of others. And it's not just how to wrap the data beautifully, but also how to simplify the appeal to them.
Epilogue
The described scheme has been implemented in one closed Mozart framework used by ADV for more than one year to develop web projects. In general, the tool fully justifies its existence, because it is precisely during the creation of web sites that a significant routine part is simplified. In addition, it is easy enough for a new person to grasp the essence and quickly start learning to directly develop projects.
In the near future, Mozart is likely to be published open-source under one of the free licenses.
Source: https://habr.com/ru/post/71279/
All Articles