Организация структуры каталогов моего веб-приложения на основе DDD?

Я начал отходить от обычного способа создания веб-приложений MVC и обратил внимание на проект, управляемый доменом — DDD.

Из одного Models теперь у меня есть Collections, Entities, DataMappers и Repositories в моем приложении для работы. Полноценное разделение и модульность, конечно, но теперь моя структура каталогов представляет собой не что иное, как полный бардак!

Поскольку я никогда раньше не работал с DDD-приложением, я плохо представляю, как организовать свою файловую структуру.

Будет ли ниже подходящая структура каталогов?
Примечание. Я использую PHP5, но считаю, что этот вопрос не зависит от языка.

/application
    /common
        /libraries
        /helpers
    /temp
        /cache
    /domain
        /collections
        /entities
        /datamappers
        /repositories
    /ui
        /controllers
        /view

php domain-driven-design directory-structure
person Industrial    schedule 09.08.2011    source источник

Ответы (1)


arrow_upward
5
arrow_downward

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

    /common
        /helpers
             /Authentication
                 /AuthenticationService.php
             /Printing
                 /PrintingService.php
    /domain
        /entities
             /Authentication
                 /Identity.php
             /Printing
                 /Printer.php
        /datamappers
             /Authentication
                 /IdentityDataMap.php
             /Printing
                 /PrinterDataMap.php

Поработав в такой системе, я могу сказать, во-первых, что очень трудно удерживать границы между модулями от взаимного зацепления только потому, что люди работают в слоях и думают о слоях как о «всех вместе». Просто с организационной точки зрения мне не очень нравится иметь три корневых каталога, открытых для работы с конкретным модулем. Мы организуем проекты в каталоги, чтобы с ними было проще работать нам, а не компилятору.

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

    /domain
        /Printing
            /entities
            /datamappers
            /repositories
        /Auth
            /entities
            /datamappers
            /repositories
    /ui
        /controllers
        /view
person Steve    schedule 09.08.2011
comment
куда бы вы поместили свои ценные объекты? - person n3wb; 10.12.2013