Handling data is a significant architectural issue for business applications. In any case, the entire application's work process is built around data. Furthermore, while in some classes of software systems the data is secondary, in business applications the data is the main content of the tasks solved.
Here (in this article) we are not talking about the technical aspect of storing and manipulating data, but about defining data as a way of designing an application. So why is data so important for business applications?
Because they describe the subject area itself. What subjects there are in business and how they relate to each other. The data also describe very clearly the problem to be solved. After all, when designing applications, we are not interested in all data, but the data (and their interconnections) that in some way affect the problem to be solved (including some reserve of system development in potentially interesting directions). For instance, if we automate the process of personnel development, we will be interested in employees' education and work history. We won't be needing the data on clothing and shoe sizes. But if we, for example, want to automate the accounting of the uniform, then it gets interesting. Although, the inquisitive architect can also raise the question here. Where there is staff development, there is motivation. And where there is motivation, there is the possibility of producing clothing with the company's logo. Here you can see that the amount of data is infinite, and the art of data modeling largely determines the art of application design.
Of course, processes are also essential in business applications. Although we would like to (and the developers of other business application development platforms as well) put more weight on processes in application design, but the data is still the most significant aspect of the subject area. The basic application model is explicitly built on the reflection of the data.
Let us make a small reservation. The term "data" here also refers to the data, accompanying the processes. It means that processes are also indirectly expressed through the data model.
Platform 1C:Enterprise includes mechanisms to reflect the processes specifically, but this is a subject for a separate article.
There are several established data handling paradigms.
First of all, there is the classic relation model. It describes data in the form of relational tables (usually stored in relational DBMS). This paradigm, although not exactly new, remains quite relevant.
There is also an object paradigm. It describes data in the form of programming language objects and somehow stores them in the database. This can be a relational or an object database. In the first case, the modeling capabilities are determined by DBMS, in the second case they are determined by the ORM used.
There are techniques and approaches that are used less frequently (when creating business applications). For example, the approach based on semistructured data.
Now, let's talk about the approach that we have chosen for the 1C:Enterprise platform. There is no officially accepted name for it. Let's call it the "applied object type model". The idea behind this approach is that the platform offers the developer a certain set of applied object types. Each type is intended to represent a specific category of domain entities in the application model. The application developer, when reflecting the subject area of the active task in the application model, should select suitable object types and use them to describe the data model. In fact, in doing so, the developer describes not only the data model but also the model of the application itself to a great extent. But more on that later.
What is a type of applied object?
This is a template embedded in the platform (you can also consider it an abstract class) that defines many different aspects of working with domain entities.
The types of applied objects appear both during development (design-time) and system operation (run-time). In design time it is a meta-model for describing objects in metadata and classes for manipulating data in the program model. In run-time, there are different aspects of the system's behavior when dealing with objects of this type. For example, the behavior of the lockout mechanism.
There are several types of applied objects in 1C:Enterprise.
Let's consider three types as an example:
· Accumulation registers
The catalogs are intended for certain conditional-constant information reflection in the system (lists of employees, goods, clients...).
The documents reflect certain events of the subject area (sales, hiring of an employee, transfer of money to the bank). Sometimes they are referred to by the names of the printed forms ("payment order", "employment order", ...). But this is done only for comprehension convenience. This is the type of event, not of the printed form.
Accumulation registers are designed to reflect a certain accounting system in the application. For example, accounting for the keeping of cash or goods in warehouses.
Let's see what is included in the "set" of features provided by applied object types.
First of all, an applied object type describes a data model and provides a mapping of data onto a relational storage model. But this is only a small part of what it defines.
For example, for a catalog:
· there are several standard attributes (fields) embedded directly in the platform (reference-identifier, code, name, reference to the parent for a hierarchical catalog, ...)
· custom (arbitrary) attributes (fields) can be described
· tabular parts can be described, which represent closely related entities (containment) or they can also be considered as nested tables
The situation similar for the document, but there is a standard attribute "Date", reflecting the status of the event relative to other events on the time axis, as well as the attribute "posted", which determines whether the document is reflected in the accounting system or is considered a draft.
For the accumulation, register fields are divided into dimensions, resources, and attributes. Dimensions describe the coordinate system of the accounting model (for example goods, warehouse), resources describe indicators (for example quantity, amount), attributes just describe additional fields (not affecting the accounting model, but commenting on the records of movements).
Why do we operate with applied object types and do not operate with just tables (or just entities)?
This is a critical point. Tables have many advantages. They are closer to the simplest modeling in the relational model, they do not limit the developer within the boundaries of the embedded types. But the tables do not offer the capabilities, provided by the approach, chosen by us.
The point of our approach (in simple words) is that in our approach the system (platform) itself "knows a lot" about the described objects and "knows a lot of ways of dealing with them". Based on this knowledge and skills, the system automatically ensures the operation of more than a dozen different mechanisms, working directly or indirectly with these objects. So it turns out that the application developer chooses the type of object and describes a particular object. And the platform, knowing the type and description of a particular object, provides a variety of useful features and mechanisms by itself. This is achieved due to the fact that the semantics of objects of this type is defined at the level of the object type (objects purpose - "big scale"), and the metadata model allows you to specify the semantics of a particular object through various properties and specialized models describing various facets.
Here's a few of them:
· First and foremost is the creation of data structures for storage and automatic transformation of the structure when the model changes
· A set of classes in an object model to manipulate data (read, write, search)
· Object-relational transformation mechanism
· A set of standard data processing procedures. For example, it is automatic numbering for documents, calculation of totals for the register, obtaining a cross-section of balances at a particular point in time, etc.
· Reflection in the system of rights. Since the system knows the purpose of the object, it also knows the applicable rights for that object.
· Visualization (reflection in the interface). Again, knowing the purpose and role of objects, the system automatically constructs commands in the application interface to access objects of this type, forms for review and modification, and commands for different actions with the object.
· Data exchange. Based on the knowledge of data semantics, the platform provides a standard mechanism for the asynchronous exchange of modified data both among related applications (distributed database nodes) and between heterogeneous applications (written both on 1C:Enterprise and other technologies)
· Object and transaction locks. To properly build a locking system, you need to know about the data's purpose and the interrelations.
· Feature mechanism (of additional user-defined fields)
· Automatically provided REST interface (by OData standard)
· Export and upload of data to XML, JSON
· In addition, the following mechanisms automatically function full-text search, logging of data access, etc.
The diagram does not show all the mechanisms of the platform, that work based on applied objects, but only some of them.
In some way, the applied object types overlap with the aspect-oriented approach. Since all of the listed features are certain predefined aspects that reflect the types of applied objects. One might say that applied object types are not just templates, but parametrized templates. Parameterization is done through a set of metadata properties. By selecting a property value, the developer parameterizes the pattern of the selected applied object type and specifies by that the behavior of the object in a particular aspect. For example, the developer can select the type of document numbering (within a year, quarter, month...) and the system will automatically provide assignment and control of numbers with a given frequency.
Applied object types provide insight into the semantics of not only the entities themselves but also the semantics of their relations. For example, there is a standard connection between documents and registers that reflects how events in the subject area are represented in the accounting model. By defining such a connection, the developer immediately gets a ready-to-use functionality on the combined lifetime of the document and register entries, associated with it.
Separately, it is worth mentioning the important subject-oriented aspects.
For example, for catalogs, it is possible to enable hierarchy support with a single checkbox. At the same time, the system will provide the support of hierarchical catalogs in every aspect: in the user interface, in reports, in the object model.
By setting a single Catalog property "Hierarchical Catalog", it immediately supports the hierarchy in the user interface, in reports and in the object model.
For documents, there are features, such as journals, that combine several types of documents, continuous numbering by period, etc.
For accumulation registers the most important feature is the automatic storage of calculated totals and ready-to-use virtual tables to access the results in different sections and with frequency counted in.
This means that, in fact, the types of applied objects contain a significant part of the universal (typical) application domain logic mechanisms, typical for the corresponding category of subject area data.
This means that the developer assembles the application from the objects of the selected types, as if they were parts of a construction set. Furthermore, if there are construction sets with "abstract" parts, then our set has the parts already with a "purpose" - wheels, windows, doors...
Based on the "Catalog" type, the developer builds Catalogs of products, employees, currencies, clients; based on the "Document" type the developer builds documents "Purchase Order", "Invoice", "Sales Order", etc.
It is also worth mentioning the methodological value of this approach. All developers operate with a certain set of concepts that helps them better understand the essence of applications and simplifies communication. When opening an unfamiliar 1C:Enterprise project, the developer immediately sees familiar terms and can quickly figure out what role a particular object plays in the system. For example, to understand the core of an application, it is worth looking at the composition of the registers - usually, it reflects the main purpose of the application. If you open the structure of tables or the structure of classes of an unfamiliar application, written in tools that operate with tables and classes, there will be much less understanding.
But, more importantly, this approach bridges the language of developers and business representatives (or analysts). The need for such a language is well explained in the book "Domain-Driven Design (DDD). Tackling Complexity in the Heart of Software" by Eric Evans. The types of applied objects become understandable reasonably quickly to non-programmers, and it allows analysts, customers and developers to discuss the basic functionality of the project in one language. Often you can encounter business representatives or analysts with no knowledge of programming, but they can set the task in terms of applied objects types in 1C:Enterprise.
Other interesting aspects. This approach ensures the continuous development of the system. We add new mechanisms to the platform, and they immediately start working for existing objects (with little or no effort on the part of the application developer).
For example, we recently developed a mechanism for storing data history (versioning). Since the system knows about data semantics in general, all the developer has to do is check a box, indicating that he wants to store the data history of a particular object, and the platform provides everything that is needed, from history storage to visualization - displaying the revision history to the user in the form of various reports. When we previously developed a standard REST interface mechanism (based on the OData standard), there was an out-of-the-box REST interface in all applications. The developers didn't have to tweak anything. Why don't we also do "just tables" (in addition to the ready-to-use applied object types)? This is a complex question. We ask ourselves that from time to time.
On the one hand, it seems tempting. By doing this, we would close all the conflicting cases where the subject area does not fit perfectly into the set of applied object types that we have prepared. We could just tell the developers: "Here's a table for you, do whatever you want with it". On the other hand, it will lead to the fact that all our standard mechanisms will be "in disarray" - how should they deal with these tables? After all, they will not know the semantics of the data and will not be able to understand how to work with it correctly. Well, you can work with them "somehow". Strictly speaking, we have that experience in terms of external sources. For external sources, we describe namely tables (without specifying the subject matter). So the system works with them in some universal way - in this case, some functionality is not supported.
For now, we still try to avoid introducing "just tables" to ensure the purity of the model and the ability to add new functionality, relying on the knowledge of the semantics of all the data. If some features are lacking, we will first take a look at how we can develop the structure of applied object types. Of course, this is a debatable issue, and we will continue to think about it.
Thus, the opportunities that the 1C:Enterprise platform provides in a ready-to-use form, and the increase in the level of abstraction, which is valued by application developers, are largely based on a set of applied object types. This is one of the most significant differences between 1C:Enterprise and other development kits, and one of the main tools for rapid and unified development.