JS: Building abstractions with data
2026-02-21 02:47 Diff
https://hexlet.io/courses/js-data-abstraction/lessons/ontology/theory_unit

Programmers always write programs for specific subject areas. For example, accounting software is based on accounting rules, and websites, where you can watch TV shows, are designed around concepts from the TV industry, such as seasons and episodes. The same goes for everything else; booking flights and hotels, finding tours, selling and buying cars, and so on.

Understanding the subject area that you're writing a program for is just as important as knowing how to program. This does not mean you need to know it thoroughly – sometimes the field can be really complicated (for example, accounting or technological production), but a general understanding is still required.

Let's consider Hexlet since you know it a little already. You know the subject matter quite well, though you've hardly thought about it the way we're going to do it now. First of all, to understand it, we need to highlight the key concepts. Learning resources tend to be divided into courses and lessons but there are actually many more ways to sort them. With Hexlet, we also have professions, challenges (practice tasks to do after the course), code reviews, quizzes, course participants (you become a participant when you join the course), and projects. This list could go on and on. You'll probably be surprised, but there are over 200 of these concepts on Hexlet, also known as entities, and they're all defined using code.

The entities have a kind of relationship with each other. For example, the quiz contains/aggregates questions. And each question, in turn, contains the answers. A profession consists of courses, and courses consist of lessons, and lessons consist of theory, quizzes, and practice. These connections have specific names. For example:

  • One lesson may only be in one course, but a course contains many lessons. This connection is called “one to many”.
  • Many users can take one course, and one user can take many courses. This connection is already called “many to many”.
  • A one-to-one relationship is less common. On Hexlet, lessons and exercises are connected in this way.

In reality, it's even more complicated because the same entity can look wholly different from different systems' points of view. A Hexlet user from the accountant's perspective (we do have an accountant!) and from tech support's perspective are two different things.

The description of some area's entities (or domain) in question and the relationships between them is called a domain ontology. The experts in the relevant field have a strong mental model and understanding of such ontology (an accountant knows accounting, a teacher knows education theory). But unlike programmers, they often present it on an intuitive level, informally. In practice, programmers (or business analysts and managers) communicate with customers, who may themselves act as experts and build a formal ontology with them (this constantly occurs in the process of project development and is not isolated to separate design phases). In other words, they single out specific terms and agree on what they mean and how they relate to each other. Then, using the ER-model the programmer creates the necessary data model. The ER model is used in high-level (conceptual) database design. This is the stage at which the beginnings of the architecture of the future application start to appear.

It's rarely possible to say unequivocally what connection exists between the two entities. Sometimes programmers think ahead and immediately build more complex relations, such as m2m rather than o2m, which affects the code complexity. The more complex the relation, the more code and money it takes to create and maintain it. The relations complexity can be ordered as follows (in ascending order): o2o, o2m, m2m. Sometimes programmers make a mistake when choosing a relationship, which indicates a poor understanding of the subject area. Here's an interesting example. Imagine a system that needs to have a user and a passport. Intuitively, there's a one-to-one relationship between these concepts, after all, one user can only have one passport. Right? Not quite; the passport can be changed if it has been lost or expired. In addition, some countries allow you to have several passports at the same time.

On the other hand, the real world is always more complex and way more significant than any model. And the programmer's task is not to create a universal and comprehensive model to cover a given area but to understand the needs of a particular business, choose only the relevant parts of the subject area under consideration, and turn them into code.

Depending on the language resources, the way entities are represented in code can vary. Some have types (using ATDs, interfaces, or classes), others define structures, and others provide no options at all except dictionaries (associative arrays).

Object-oriented programming (OOP) is directly related to the topic at hand. In the next lesson, we'll start exploring different subject areas and building suitable data models, while learning new features of JavaScript in the process.

The topic in question will be most fully explored when we start learning about ORM. For now, the main thing is that you have a general idea of the subject area, entities, and relationships. Don't forget to read the information on the links provided – the more questions you have at this stage, the better.