В корне репозитория обычно создается директория src, которая хранит список модулей системы.
Раньше я придерживался политики доступа и права взаимодействия (теперь считаю это решение неверным, но для истории решил сохранить его):
| Имя модуля | Описание | Доступ |
| Core | ядро проекта | не может взаимодействовать ни с одним модулем системы, но любой модуль может взаимодействовать с модулем Core |
| Report | отчеты/статистика | может взаимодействовать с любым модулем, но ни один модуль не может взаимодействовать с модулем Report |
| ModuleName | любой другой модуль | может взаимодействовать только с модулем Core, ни один модуль не может взаимодействовать с модулем ModuleName |
Данные правила доступа были обусловлены требованием обеспечить минимальную связанность модулей проекта + исключить возможную рекурсию.
Теперь мое мнение таково, что модули могут общаться друг с другом, но границы общения должны быть четко обозначены (например используя паттерн Медиаторов, пример реализации Module1Module2Mediator).
Структура модуля имеет обязательные и необязательные директории, ниже изложена структура модуля, описанная максимально абстрактно, но с примерами реализации. Итак, рассмотрим возможное содержимое директории src/ModuleName/
| Адрес к директории или файлу | Тип | Описание |
| Docs | Folder | Хранит документацию по текущему модулю |
| - README.md | File | Файл описывающий некоторые тонкости по использованию данного модуля |
| Configuration | Folder | Хранит настройки модуля |
| - RouteProvider.php | Class | Реализует маршрутизацию модуля (связь запросов и обработчиков запросов) |
| - DependencyInjectionProvider.php | Class | Реализует подключение сервисов модуля в Dependency Injection Container |
| Data | Folder | DataAccess Layer - слой хранения данных (это сущности, модели и data-провайдеры внешних сервисов) |
| - User | Folder | Пример директории, в которой хранятся файлы по работе с пользователями |
| - - UserModel.php | Model | Класс работы с пользователем (чистая модель - не хранит запросы по работе с др. таблицами бд). Нельзя бизнес-сервисы дергать из моделей. |
| - - UserDsp.php | Service | Dsp (data source provider) - класс с функциями, в которых реализуется работа c данными. Очень важный момент: метод DSP всегда выполняет только одну функцию и не хранит бизнес-логику и не занимается форматированием/валидацией данных, его обязанность сохранить/возвратить/удалить данные. Пример: при работе с данными пользователей, таблица пользователей обязана быть главной таблицей из которой выбираются данные, остальные таблицы второстепенные (JOIN к ним может быть, а может и не быть). |
| - - Enum | Folder | Место расположения файлов-списков, оформленный с помощью интерфейса с константами |
| - - - UserFieldEnum.php | Interface | Список полей в бд, которые могу быть названы с ошибками или на русском, в общем которые нужно зарефакторить, но времени на это пока нет |
| - - - UserTypeEnum.php | Interface | Список типов пользователя |
| Business | Folder | Business Layer - это Application Layer (слой хранения бизнес-логики предметной области) |
| - MedicalService | Folder | Хранит сервисы медицинских услуг (поэтому имя директории содержит суфикс Service, иначе суфикс Service писать директории не нужно). Функции сервиса содержат только бизнес-логику (валидация или форматирование данных выполняется за его пределами). |
| - - Dto | Folder | Хранит классы реализующих паттерн Dto |
| - - - SomeDto.php | Class | Используется для передачи данных между подсистемами модуля/модулей |
| - - Template | Folder | Хранит список файлов-шаблонов (мы используем twig по-умолчанию для всех backend шаблонов) |
| - - - MailTemplate.twig | File | Шаблон письма для отправки на email |
| - - Formatter | Folder | Хранит классы позволяющих форматировать данные медицинских услуг |
| - - - MedicalServiceFormatter.php | Service | Классов позволяющих форматировать данные услуг |
| - - MedicalFacade.php | Service | Позволяет взаимодействовать с медицинскими услугами (любой класс-фасад с именем из одного слова, обязан иметь суфикс Facade) |
| - Patient | Folder | Хранит сервисы по работе с пациентами |
| - - PatientFacade.php | Service | Фасад - хранит все методы по работе с пациентом (тут объявляются все зависимости и существующие бизнес-трейты) |
| - - Handler | Folder | Директория хранит хендлеры по работе с пациентом, идеологично похожие но не имплементирующие RequestHandlerInterface Функция хендлера:
|
| - - - PatientOrdersTrait.php | Trait | Трейт реализует работу с заказами пациента |
| - - Request | Folder | Директория хранит объекты запросов (в данном примере потому, что PatientOrdersHandler.php доступен наружу) |
| - - - PatientOrdersRequest.php | Class | Объект запроса полученный с помощью JMS\Serializer\Annotation |
| - - Response | Folder | Директория хранит объекты ответа (в данном примере потому, что PatientOrdersHandler.php доступен наружу) |
| - - - PatientOrdersResponse.php | Class | Объект ответа полученный с помощью JMS\Serializer\Annotation. Плюсы использования JMS\Serializer\Annotation: - строгая типизация запросов/ответов - ООП подход - автоматическая документация |
| - - - Translation | Folder | Директория хранит файлы переводов ответов с английского языка |
| - - - - Ru.yaml | Yml | Файл перевода с английского на русский |
| Infrastructure | Folder | Так называемый инфраструктурный слой, например классы реализующие какой-то общий функционал или расширяющие функциональность сторонних библиотек (бизнес-логики тут нет) |
| - Logging | Folder | Хранит файлы расширяющие функционал стороннего модуля для логирования (например Monolog) |
| - - Enum | Folder | Хранит файлы-списки |
| - - - ChannelEnum.php | Interface | Списком каналов логирования |
| - - Processor | Folder | Хранит процессоры, которые обрабатывают данные логирования |
| - - - SessionProcessor.php | Class | Процессор, который обрабатывает каждую запись отправляемую в лог |
| - Database | Folder | Хранит классы реализующие работу с базой данных |
| - - MySQL | Folder | Хранит классы по работе с б.д. MySQL |
| - - - Enum | Folder | Хранит файлы-списки |
| - - - - TableNameEnum.php | Interface | Список таблиц б.д. |
| - - - - NumericEnum.php | Interface | Особенности целочисленных типов данных (пример) |
| - Validation | Folder | Классы валидации разного вида данных |
| - - ScalarValidator.php | Service | Класс с методами валидации скалярных данных |
| - Middleware | Folder | Presentation Layer - классы реализующие обработку запроса (отвечают за преобразование протоколов и кодирование/декодирование данных) |
| - - Request | Folder | Директория хранит Handler-классы реализующие MiddlewareInterface |
| - - Response | Folder | Директория хранит Handler-классы реализующие паттерн ResponseListener |
| UI | Folder | user interface — по́льзовательский интерфейс (Front-end) |
| - Vue | Folder | Хранит файлы и директории vue компонентов (структура SPA-приложения на Vue.js) |
| - - App.vue | File | Основной файл конфигурации текущего модуля |
| - - Router.vue | File | Основной файл роутов текущего модуля |
| - - Component | Folder; | Директория компонентов |
| - - - PatientOrders | Folder | Хранит файлы компонента, которые будут скомпилированы |
| - - - - PatientOrders.vue | File | Содержит подключение шаблона, скрипта и стили vue компонента, все это будет скомпилировано |
| - - - - PatientOrders.js | File | Скрипт vue компонента |
| - - - - PatientOrders.css | File | Стили vue компонента |
| - - - - PatientOrders.html | File | Шаблон vue компонента |
| - Bootstrap | Folder | Пример расширения еще одно всем известной фронтенд библиотеки |
| - - Theme | Folder | Собственная тема |
| - - - Office | Folder | Место применения |
| - - - - Tree.css | File | Файл, который расширяет/переопределяет тему библиотеки |
| Tests | Folder | Хранит тесты подсистем модуля |
| - Functional | Folder | Хранит функциональные тесты подсистем модуля |
| - Unit | Folder | Хранит одиночные тесты подсистем модуля |
| - bootstrap.php | File | autoload-файл для тестирования на основе подмены классов (используется только в модуле Core) |
| Pattern | Folder | Хранит список паттернов используемых в данном модуле (если паттерн используется в нескольких модулях, то кладется в Core\Pattern |
| - DaoInterface.php | Interface | Интерфейс для правильной реализации паттерна |
В выше обозначенной структуре важно, чтобы имена директорий/файлов пишутся в стиле UpperCamelCase (PascalCase)
Код интерфейса лучше хранить в отдельной директории модуля. Предлагаю, рассмотреть вариант, когда UI написан на языке JavaScript и популярном сейчас фреймворке Vue (главной особенностью которого является факт того, что все в нем является компонентом).
Скомпилированный файл UI-компонента должен быть размещен в публичной директории, содержащей имя директории UI-компонента.
На примере PatientOrders-а, это директория: public/UI/ModuleName/PatientOrders в которой js, css и html, будет скомпилированы в Build.js
Файл Build.js не должен попасть в систему контроля версий (например git), поэтому следует добавить в .gitignore игнорирование всех файлов Build.js
Если предполагаются какие-либо медиа-файлы, то их следует размещать в директории public/Resource/ModuleName/PatientOrders/
Например:
| Путь | Описание |
| public/Resource/ModuleName/PatientOrders/Image | Директория с изображениями |
| public/Resource/ModuleName/PatientOrders/Pdf | Директория с PDF-документами |
| public/Resource/ModuleName/PatientOrders/Zip | Директория с архивами |
Директории UI и Resource расположены выше по иерархии по следующим причинам:
Источник: 1 - 2- 3 - 4 - 5 - 6 - 7 - 8 - 9
Комментарии
Комментариев пока нет.