Как грамотно спроектировать структуру приложения?

Question

[Дмитрий]

Имеется следующая структура:

В приложении имеются следующие сущности:

• Автомобиль (база автомобилей их параметров и прочее)
  
• Комментарий
  
• Гео
  
  • Область
    
  • Район
    
  • Город
    
  
  
• Продукт
  
• Продажа
  
• Пользователь
  
  • Автомобиль, которым владеет юзер
    
    • Водитель автомобиля
      
    
    
  
  

Вопросы:
1. Entities - сущности приложения. Корректно ли я оперирую этим понятием?
2. Каждая сущность будет содержать (при необходимости) имплементацию репозитория, сервиса, бизнес-модель (DTO), ActiveRecord (например для связей) - это "ок" или нужно как-то по другому организовать инфраструктуру для каждой сущности?
3. Годится ли подобный подход для инкапсуляции бизнес-логики в отдельный слой?

Comments

[Дмитрий]

Некоторые сущности из скриншота были опущены в тексте. Но пример цельный, суть не меняется.
Если нужны какие-либо уточнения - спрашивайте.

[yurygolikov]

Можете почитать про DDD
Есть также неплохая книжка domain driven design эрик эванс

[Максим Тимофеев]

Не думаю, что по данному скриншоту и паре строчек описания, можно делать выводи и что-то советовать. А самое главное не понятно что Вы вкладываете в "грамотно"? Поставят ли за это 5 - это один вопрос. Удобно ли будет с этим работать - второй. Соответствует ли это ряду стандартов - третий.
Но самый главный вопрос, а при чем тут yii?

[Дмитрий]

Максим Тимофеев:
Мне казалось, что я достаточно подробно описал входные данные: структуру, паттерны(AR, Repository, Service, DTO).

Грамотно === можно ли работать основывая проект на подобной структуре?
Но так же было бы неплохо получить рекомендации по стандартам, которые применяются при построении объёмных приложений.

Yii тут ни при чём, просто указал для полноты картины, так как проект разрабатывается на Yii2.

[Евгений Шатунов]

Дмитрий , по изложенной картине можно гадать как по кофейной гуще. Эффект будет таким же.

Хорошо, ты уже написал что будешь основывать на этом проект. А что это за проект? Какие у него цели? Какие функции?
Я достаточно часто встречаю ситуацию, когда вместо того, чтобы описать мне задачу, мне пытаются предоставить информацию как эту задачу решать. И информацию дать пытаются именно те, от кого это никогда не потребуется.

У тебя есть вопрос, но нам ты его не задаешь. Вместо постановки самого вопроса ты спрашиваешь верно ли некоторое решение твоего вопроса. Можно ли дать качественный ответ в такой ситуации?

Answer 1

[Максим Федоров]

ох что-то Вы не понятное пытаетесь построить. Судя по вопросу у Вас набор паттернов а не архитектура. Что Вы хотите получить в итоге? слоенную архитектуру? так она так не строиться. DTO - это объект для передачи данных, он не хранит бизнес-логики, репозиторий и Active Record как правило не используются совместно. В общем судя из постановки задачи могу сказать что Вы не совсем понимаете как строить подобную архитектуру, поэтому рекомендую Вам вначале почитать про слоеную архитектуру (например у того же Фаулера), про модель предметной области, про DDD, а потом уже переходить к практике. Для начала можете пробежаться для начала по этим статьям:
статья 1
статья 2
статья 3
статья 4

Comments

[Дмитрий]

Дело в том, что данный проект не предполагал в своей основе DDD.

Планировалось выделить сущности бизнес-модели, для каждой сущности определить:
- слой взаимодействия с хранилищем (Repository и AR для обмена данными с БД)
- сервисный слой (Service) для работы с данными
- бизнес-модель (DTO), где определить требуемый перечень аттрибутов и работать в дальнейшем через эту модель.

То есть при обращении к сущности выстраивается следующая последовательсть:
Controller -> Service -> DTO -> Repository -> ActiveRecord.

DDD, в моём случае, избыточен, не так ли?

Со статьями ознакомлюсь, спасибо.

[Максим Федоров]

Дмитрий: сложно сказать избыточен ли DDD т.к. не понятны масштабы Вашего проекта. Если у Вас проект маленький возможно вообще не стоит заворачиваться над слоями, а использовать стандартный для yii (насколько понимаю о нем идет речь) подход с использованием Active Record.

Answer 2

[vism]

Можно только сказать, что семантика папок верная (папочка вложена в другую папочку корректно)
А больше тут что сказать?

Намного важнее, чтоб вы следовали стандартам фреймворка, верно разносили логику по моделям, делали тонкий контроллер и т.д.
Обычно вобще логику диктует реляционная бд, если вы ее используете.
Верно построите БД, все само по себе и в коде выстроится.

Answer 3

[Дмитрий Евграфович]

Как минимум стоит переименовать одинаковые сущности автомобилей. Либо создать caruser для авто пользователя, либо cardata (carinfo) для информации по автомобилю.

Comments

[Дмитрий]

Это мелочи.