Ответы пользователя по тегу Проектирование программного обеспечения
  • Как оптимизировать задачу?

    @PiloTeZ
    ...
    Можно попробовать вынести в очередь (RabbitMQ например, обрабатывать каждого клиента отдельной задачей в очереди) и выполнять задачи несколькими воркерами, то есть параллельно. Единственное, важно что бы вас не забанил сторонний сервис и вы не положили его нагрузкой. Что бы регулировать нагрузку, нужно менять количество воркеров обрабатывающих поступающие задачи
    Ответ написан
    Комментировать
  • Как улучшить контроллер, метод, архитектуру?

    @PiloTeZ
    ...
    - Начните выносить логику из экшенов контроллера в сервисы
    - Для упрощения, первое время можете делать по принципу "один контроллер - один сервис", "один экшен - один метод сервиса". Если используете QueryBuilder в GET экшенах, это можно не выносить в сервисы, первое время только геморой получите
    - Не бойтесь разбивать конроллеры на более мелкие. Если в контроллере много экшенов, или есть повторяющиеся слова в названиях экшенов, или экшены называются более, чем 2-мя словами, часто это признак, что контроллер выполняет слишком много действий. Например есть контроллер ArticlesContrller с экшенами createArticle, updateArticle, addArticleToFavorite, deleteArticleFromFavorite. Получается дичь, он будет бесконечно разрастаться и поддержка усложнится. Например если разбить на ArticlesController (create, update, delete, deactivate) и FavoriteArticlesController (add, delete), то станет ведь гораздо проще. Так же и с сервисами. Это принцип Single responsibility
    - Если метод сервиса становится слишком большим, то лучше вынести его в отдельный класс. Например есть метод Orders::create(). Создайте папку orders там же где находится сервис, в нем создайте класс OrderCreator с параметрами в конструкторе, как у метода Orders::create() и сделайте один метод create(). Заюзайте его в классе Orders::create(). Далее разбейте OrderCreator::create() на мелкие приватные методы
    - Старайтесь делать методы как можно меньше, тогда они будут более гибкими и вы сможете их использовать в других местах, так же и с классами
    - А вообще, зачем пересказывать книги. Просто прочитайте Фаулера Рефакторинг. Пробуйте разные описанные там принципы, и не стесняйтесь делать прямо так, как там написано. Это очень важная книга, которые выведет ваш код на абсолютно другой уровень

    Дополнительно
    - Рекомендую вести какой-нибудь блокнот, где брать термины и описывать своими словами. То есть постараться понять его и зафиксировать то, что поняли
    - Не занимайтесь перфекционизмом. Не бывает идеального кода. Читайте теорию, пытайтесь использовать на практике. Как можно больше практики основанной на теории
    - Начинайте с малого. Не надо применять и читать сразу все
    - Знайте меру. Если что-то узнали, не значит, что нужно теперь применять абсолютно везде, бездумно. Если считаете, что здесь это неуместно, не используйте, даже если написано иначе
    - Параллельно можно пробовать применять различные принципы: SOLID, KISS, YAGNI, DRY. Вернее не SOLID, забудьте про него вообще, первое время только голову нагружать будет, а именно Single responsibility.
    - В какой-то момент применяемые принципы могут показаться бессмысленными, тогда попробуйте что-нибудь сложнее CRUD. Например сделайте свой Pat project для практики
    Ответ написан
    1 комментарий
  • Как построить такую же архитектуру приложения как на profi.ru?

    @PiloTeZ
    ...
    В основе архитектура простая.
    3 таблицы: категории (название), атрибуты категорий (название, тип, категория), значения атрибутов (атрибут, значение, заказ).
    - управление атрибутами через админку
    - на стороне представления при создании заказа генерируется форма на основе параметров атрибутов
    - при сохранении формы атрибуты попадают в соответствующую таблицу

    Образно говоря: это генератор форм, с привязкой к категориям.

    Для улучшения гибкости решения, можно не связывать атрибуты напрямую с категориями, и сделать это через отдельную таблицу-связь. Тогда генератор форм можно будет использовать не только для категорий, но надо ли
    Ответ написан
    Комментировать
  • Как спроектировать сервис для повторного использования?

    @PiloTeZ Автор вопроса
    ...
    По итогу решил следующее. Если нужно быстро, то сделать через параметры и условия. Если логика была бы сложнее и конфликты в ней серьезнее, то нужно было бы:
    - разбить метод create на protected методы
    - вынести новые методы в базовый класс
    - унаследоваться от базового класса и создать Companies и AdminCompanies
    - в Companies и AdminCompanies сделать create метод с нуля на основе базовых методов
    Ответ написан
    Комментировать
  • Как решить, когда использовать роли пользователя или учетную запись типа пользователя?

    @PiloTeZ
    ...
    1. Отвязываемся от пользователя, оставляем там только поле type и варианты значений Admin, User
    2. Под каждый тип пользователей создаем таблицу: partners, clients, operators
    3. Определять является ли пользователь партнером, клиентом или оператором нужно по наличию записи в этих таблицах
    4. Определять тип партнера можно добавив поле specialization_id в partners
    5. Определять набор предоставляемых услуг партнером, можно добавив таблицу services и связав ее со specializations

    Структура БД:
    users - пользователи
    - id
    - type [admin, support, user]
    clients - клиенты
    - id
    - user_id
    - title
    operators - операторы
    - id
    - user_id
    - title
    partners - партнеры
    - id
    - user_id
    - specialization_id - специализация партнера
    specializations - специализации (врач, медсестра, массажист)
    - id
    - title
    services - предоставляемые услуги (массаж, обследование...)
    - id
    - title
    specialization_services - связь между специализациями и услугами
    - id
    - specialization_id
    - service_id

    Итого:
    - не нужно усложнять сущность пользователя
    - пользователь может быть партнером, клиентом, оператором и т.п.
    - признак партнерства, клиенства и т.п. определяется наличием записи в соответствующей таблице
    - в партнерстве помимо названия, хранится его специализация (врач, медсестра и т.п.)
    - услуги отображаются в зависимости от специализации, используя связь между таблицой специализаций и услуг
    - если подобная структура данных слишком гибкая, ее можно ограничить программно
    - проверку прав делать в зависимости от контекста
    - например если это кабинет партнера, то смотреть, есть ли запись в таблице партнерства
    - решение может показаться усложненным, но на самом деле дает гибкость и более простое понимание бизнес логики в дальнейшем
    Ответ написан
    Комментировать
  • Какие книги по IT архитектуре почитать?

    @PiloTeZ
    ...
    • Эрик Эванс - предметно-ориентированное проектирование"
    • Мартин Фаулер - рефакторинг
    • Роберт Мартин - чистая архитектура
    Ответ написан
    Комментировать
  • Сервер электронный почты (например Mail.Ru) после удаления писем из корзины уничтожает их или они продолжают хранится на сервере?

    @PiloTeZ
    ...
    Остаются как минимум в течении 6 месяцев (не точная информация)
    Ответ написан
    Комментировать