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

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

6 голосов
/ 09 августа 2011

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

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

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

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

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

1 Ответ

5 голосов
/ 09 августа 2011

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

    /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
...