Part 2 - GymVibe [designing entities]

Дисклеймер: могут быть ошибки и т.п., темы пишутся в пьяном угаре.

Пришла идея для приложульки
Контекст происходящего. Я треню по 6 раз в неделю и трекаю количество повторений на подход в google notes, что неудобненько.
Хочу сделать либо mini-app, либо мобильное приложение, в этой части мы сфокусируемся на backend составляющей сущностей. По фронту (мобилка или mini-app) определюсь позднее, есть информация, что мобилку тяжелее вайбкодить, чем обычный фронт.

Проектируем доменные сущности.
Когда мы только-только начинаем проектировать наш бэкенд, стоит начать с доменных сущностей.
Domain - это объекты предметной области.
Предметные области компаний бывают разными: финтех, edтех и т.п.
Наша предметная область - фитнес (если можно так назвать).

Существуют разные подходы к проектированию сущностей (code-first, database-first).
Когда мы начинаем с базы данных (database-first) - мы проектируем сущности с точки зрения того, как они будут храниться в таблицах.
Когда мы проектируем с подходом code-first, нам не так важно на начальном этапе, как мы будем хранить это в таблицах - мы хотим сразу написать в коде сущности, а уже потом определиться с тем, как мы будем хранить это в БД (например, конфигурируя то, как именно будут храниться наши сущности в БД путём использования конфигураций fluent configurations Entity Framework для каждой из сущностей).

Мы воспользуемся чем-то вроде code-first, т.е. мы не будем дотошно проектировать каждое поле сущности, но хотя бы поверхностно прикинем, какие у нас будут сущности в проекте.

Я хуево спроектировал сущности, но для прототипа пойдет.

Сущности

Что есть что:

• User - пользователь (если все таки будет mini-app, то можем сунуть в него TelegramId, вес, рост * чтобы попробовать на основе частоты тренировок и параметров прикидывать норму по каллориям на сброс и набор: референс);
• WorkOut - шаблон тренировки (храним у него UserId *мб будет каталог шаблонов тренировок других людей, на которые можно будет делать свои экземпляры WorkOutDaily, Titile("Спина B"), и т.п.);
• Excercise - описание упражнения (храним у него WorkOutId, OrderIndex, Name("Шраги"), Notes("смит занят, сделал в другом месте");
• WorkOutDaily - экземпляр конкретной тренировки (ссылаемся на WorkOutId, UserId, храним Date, StartedAt, FinishedAt);
• ExcersiseSet - экземпляр конкретного подхода на упражнение (храним ExerciseId, WorkOutDailyId, OrderIndex, IsWarmup, Weight, Reps.
  
  И пока пойдет, потом можно добавлять уже всякие вспомогательные сущности (единица измерения веса фунты или кг) или для доп. функционала: MuscleGroup и хранить MuscleGroupId в Excercise, чтобы анализировать количество подходов в неделю на группу и сравнивать с оптимальным диапазоном по современным исследованиям.
  
  Сейчас не учитываются bounded context для модульного монолита или микросервисов, однако, несмотря на это, стоит посмотреть на то, насколько сильно связаны между собой те или иные сущности. Мы стремимся к сильному Cohesion (высокой внутренней связанности внутри одного модуля) и к слабому Coupling (низкой связанности между разными модулями).
  Cohesion — это насколько элементы внутри одной сущности или модуля нужны друг другу.
  Coupling — это насколько один модуль зависит от другого.
  Пример: WorkOutDaily будет хранить НЕ
  User user

  Code

  User user

  А будет хранить
  Guid userId

  Code

  Guid userId

  Так как User и WorkOutDaily это не сильно связанные сущности и вряд ли мы будем из WorkOutDaily пытаться вмешаться в User, странный пример такой ситуации
  WorkOutDaily.User.Name = "Егор".

  Code

  WorkOutDaily.User.Name = "Егор".

  Такие вещи с точки зрения работы с сущностями через EF лучше рассмотреть отдельно, конечно.
  
  Естественно, так снихуя нельзя просто взять и идеально сущности спроектировать, в процессе всегда будут всплывать моменты, что не учел что-то.
  
  В следующей части:
  Напишем доменные сущности уже кодом, посмотрим какие варианты реализации есть для валидации и для обеспечения бизнесовых ограничений (анемичные доменные модели + жирные проверки в сервисе/handler или богатые доменные модели, которые сами себе обеспечивают соблюдение инвариантов и тонкий сервис/handler).
  
  На сколько в этот раз пропаду хз, ну идея прикольная - хочется сделать
  
  Другие части:
  Часть 1 - Тыкаем палкой Asp.net, оно шевелится?