Потихоньку развиваю проект, основанный на своих (сложных) инженерных изысканиях, опубликованных тут:
https://habr.com/ru/articles/755158/
и частично, (может, не совсем удачно, но как-то по-проще) описанных тут:
https://habr.com/ru/articles/755214/
Сразу хочу предупредить, что описанное в статье - еще на разработке, и в проекте появится не скоро.
Поехали!
Обычно при проектировании учетных систем, архитектор закладывает базовые ограничения на ввод данных, пользуясь типизацией полей ввода платформы. В модель вводятся числа - «оценки», которые в последствии участвуют в целях измерения объекта, в алгоритмах учета, в аналитике, статистике. С числами работать проще, чем переопределять операции сложения, вычитания, приведения к другой размерности на других, более сложных — структурно типов данных.
Как это обычно выглядит.
Начальный этап проектирования:
Наименование (строка 10): Яблоко
Количество (число 2.0): 15
Можно на этом и остановится, но в данной модели не понятно — что значит «Количество». Не хватает размерности. Допустим, раз у нас количество — целое число, значит штуки? Может быть. А может и вагоны, и допустим... груженные корабли, целых 15 штук идут по морям и океанам... Стороннему наблюдателю эти числа ничего не сообщат. Архитектор, находящийся в контексте задачи может подразумевать — к примеру расфасованные предварительно упаковки по одному килограмму (фунту, штуке?).
На вопрос — сколько яблок — последует ответ 15. 15 — «чего»? Текущая модель не ответит. На эту информацию сможет ответить только погруженный в контекст наблюдатель.