Подтвердить что ты не робот

Реализовать DDD в MVC Frameworks - PHP

в mvc модель является слоем и содержит всю бизнес-логику домена.
в бизнес-логике, управляемой доменом, можно разделить на различные строительные блоки, например.

в доменной модели домена Driven Design.

Модель домена - это система абстракций, которая описывает выбранные аспекты сферы знания, влияния или деятельности (домена). Затем модель может быть использована для решения проблем, связанных с этой областью.

разработчик ознакомился с Domain Driven Design или использует Doctrine2 или Hibernate, обычно лучше ориентируются на модель домена в DDD. В mvc-структурах модельный слой перекрывается с моделью домена в DDD.it означает, что мы можем реализовать модель домена в папке модели в инфраструктурах mvc

такие реализации показаны ниже. показывает, как папка модели является структурой

   Model(this can model or domain)
   | 
   |----Entities
   |    |---BlogPost.php
   |    |---Comment.php
   |    |---User.php
   | 
   |----Repositories
   |    |---BlogPostRepository.php
   |    |---CommentRepository.php
   |    |---UserRepository.php
   | 
   |----Services
   |    |---UserService.php
   | 
   |----factories
   |    |---userfactory.php
   | 
   |----dataMappers
   |    |---userDataMapper.php // this inherit from Eloquent model
   | 
   |----ValueObject


  • Я хочу знать, мое первое предположение (может реализовать модель домена в папке модели в mvc-фреймворках) правильно?
  • Правильно ли это, что все строительные блоки в DDD реализуются в папке модели (как показано выше), например сущности, службы, репозитории
  • или любые другие предложения, которые вы имеете относительно этой реализации.
  • если это неверно, что является правильным способом реализации строительных блоков DDD, таких как сущности, службы, репозитории в инфраструктурах mvc.
4b9b3361

Ответ 1

в mvc модель является слоем и содержит весь бизнес домена логика.

Я сомневаюсь, что сам шаблон MVC объявляет что-то особенное о Домене. Он управляет моделью как мешок свойств и не заботится о том, как она была создана и как она защищает свои инварианты.

В то же время Архитектура Onion заявляет, что важно изолировать Domain of of Application Service (какая из них MVC Framework). Поэтому мне нравится размещать слой Domain, который содержит объекты, объекты Value, события домена и агрегаты для отдельного модуля или папки верхнего уровня.

введите описание изображения здесь

Еще одна причина размещения домена отдельно от материала MVC заключается в том, что он позволит вам управлять несколькими ограниченными контекстами, поскольку каждый контекст нуждается в собственных модуль/папки.

Я предлагаю вам проверить эту структуру ASP MVC. Он был разработан известным экспертом DDD. Помимо домена, пожалуйста, посмотрите, как организована часть MVC. Он использует метод фрагмента, который становится все более популярным в наши дни, и я нахожу его чрезвычайно полезным.

Ответ 2

Хотя я совершенно новичок в мире DDD, в процессе постепенной миграции приложения, над которым я работал, более DDD-ориентированной структуры, я также столкнулся с вопросом о структуре каталогов. Объединив информацию, которую я смог найти, которая не была полностью концептуальной, я придумал следующую упрощенную структуру каталогов (которая существует в CRUD-ориентированном приложении Laravel), который мне очень хорошо показал:

app/
    ProjectName/
        Core/
            Application/
            Domain/
            Infrastructure/
        User/
            Application/
                Services/
                    CreateUserService.php
                    FindUserService.php
                    UpdateUserService.php
            Domain/
                Role.php
                RoleDAO.php
                User.php
                UserDAO.php
                UserNotCreated.php
                UserNotFound.php
                UserNotUpdated.php
                UserWasCreated.php
                UserWasUpdated.php
            Infrastructure/
                EloquentRoleDAO.php
                EloquentUserDAO.php

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

Оставляя в стороне гибридную природу моего собственного приложения (я использую ORM-зависимые DAO/Entities, сценарии транзакций и избегаю объектов Value, чтобы назвать несколько утечек), это может все еще помочь в качестве приблизительной идеи потенциальная структура каталога DDD в приложении MVC.

Ответ 3

Я бы рассмотрел модель в MVC как комбинацию ViewModels и команд. Входящие запросы сопоставляются с командами, которые будут отправляться на уровень "write", который извлекает соответствующий агрегат и вызывает соответствующий метод, а затем совершает транзакцию.

ViewModels существуют исключительно для переноса данных в готовом формате для пользовательского интерфейса. У вас может быть очень простой слой "read", который запрашивает представления или таблицы базы данных и возвращает результаты клиенту. Это позволит вам иметь модель домена, которая не подвергает все свое состояние через геттеры и сеттеры.

Ответ 4

Я согласен с предложением @Жарро.

Хорошая структура выглядит следующим образом:

  • View (содержит только часть вида, например, twig, html и активы)
  • Ядро (контроллер, форма, слушатели, помощники)
  • BusinessLogic (включить службы)
  • Entity (Entity, Commands, Validator)

1) Просмотр доступа к части только CoreBundle и не изменяет поведение базы данных.

2) Доступ к основной части BuisnessLogic и Entity

3) Только доступ к компоненту BuisnessLogic Entity

4) База данных доступа к базе данных Entity.

Ответ 5

Ваше первое предположение неверно, MVC не подходит для DDD, лучше использовать шаблон CQRS.

Ваше второе предположение также неверно, блоки зданий не все находятся в папке модели домена, на самом деле, вот хорошая структура для вашего проекта:

ProjectName/
    Application/
        Blog/
            Command/
                CommentToBlogPostCommand.php
                ChangeCommentContent.php
                DescribeBlogPostCommand.php
                NewBlogPostCommand.php
                ...
            Data/
                BlogPostData.php
                BlogPostCommentsData.php (POPO containing BlogPost infos and the comments array)
                CommentData.php (Single comment infos)
            BlogPostApplicationService.php
            BlogPostQueryService.php
            CommentApplicationService.php
            CommentQueryService.php
        Identity/
            Command/
                AuthenticateUserCommand.php
                ChangeEmailAddressCommand.php
                ChangeUserPasswordCommand.php
                ChangeUserPersonalNameCommand.php
                DefineUserEnablementCommand.php
                RegisterUserCommand.php

            UserApplicationService.php (this defines the actions that can be done by your application related to user domain, injected in presentation layer responding to user events)
            UserQueryService.php (this will usually be injected in your presentation layer)
    Domain/
        Model/
            Blog/
                BlogPost.php
                BlogPostClosed.php (this could be a list of possible events)
                BlogPostDescriptionChanged.php
                BlogPostModeratorChanged.php
                BlogPostReopened.php
                BlogPostStarted.php
                BlogPostRepository.php (interface)
                Comment.php (this is an Entity, or Aggregate Root)
                CommentContentAltered.php (this could be an event)
                CommentAuthor.php (this could be a ValueObject, containing the username)
                CommentRepository.php (interface)
                CommentedToBlogPost.php (this could be another event when adding a comment to a blogpost)
                ...
            Identity/
                ContactInformation.php (VO or Person)
                Enablement.php (VO of User)
                EmailAddress.php (VO of ContactInformation)
                FullName.php (VO or Person)
                Person.php (ValueObject of User)
                User.php (constructor visibility might be package-protected)
                UserFactory.php
                UserRepository.php (this is an interface)
                UserService.php (this is a domain service)
    Infrastructure/
        Persistence/
            LavarelBlogPostRepository.php (this implements BlogPostRepository)
            LavarelCommentRepository.php (this implements CommentRepository)
            LavarelUserRepository.php (this implements UserRepository)
    Interfaces/
        ...

Таким образом, вы можете сохранить псевдо MVC, но с той разницей, что View и Controller находятся в пакете Interfaces, а Rich Model - в пакете domain/model. Вы можете управлять моделью только через службы приложений и запрашивать модель через службы запросов. Службы запросов обеспечивают быстрый доступ к представлению модели, а команды отправляются службам приложений для управления в качестве контроллеров.

Обратите внимание, что класс CommentAuthor может представлять собой объект Value, не содержащий идентификатор пользователя базы данных, а уникальное имя пользователя. Поскольку корень агрегата пользователя принадлежит другому пакету: это имеет смысл из домена PointOfView. Мы могли бы назвать это личность (или имя пользователя). Это было бы идеально сопоставлено с уникальным столбцом таблицы User, но будет индексированным значением таблицы Comment.

Другой вариант - использовать пакет User в блоге как часть той же концепции, которая является блогом, но DDD не рекомендует этот подход. На самом деле это рекомендовало бы поставить Identity и Access в отдельный ограниченный контекст, но я предполагаю, что в контексте приложения, которое вы пишете, отображение пользователя как части комментария может быть в порядке.

В инфраструктурном слое вы определяете своего провайдера персистентности, таким образом, в тот день, когда вы хотите переключиться на Doctrine, только изменение в этом пакете должно измениться.

Уровень приложения отвечает за управление безопасностью, охватывает транзакционный контекст и регистрирует события высокого уровня.

Я могу дать вам больше информации о внутренних классах, если вам нужно какое-то разъяснение. Кроме того, для этого может потребоваться некоторая инфраструктура или инфраструктура поддержки, я думаю:

  • инъекция зависимостей,
  • диспетчер событий доступен в entitites,
  • какая-то шина событий, если вы планируете использовать эти события.