-1

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

# 1 бизнес-домен/слой

app/ 
----accout/ 
--------application/ 
--------domain/ 
--------infrastructure/ 
----client/ 
--------application/ 
--------domain/ 
--------infrastructure/ 
----transfer/ 
--------application/ 
--------domain/ 
--------infrastructure/ 

или # 2 слой/бизнес-домен

app/ 
----application/ 
--------account/ 
--------client/ 
--------transfer/ 
----domain/ 
--------account/ 
--------client/ 
--------transfer/ 
----infrastructure/ 
--------account/ 
--------client/ 
--------transfer/ 

Какой подход будет соответствовать лучше для старого проекта? Что предпочтительнее из вашего опыта?

С моей точки зрения, № 1 позволит развязать систему во время дальнейшего рефакторинга. С другой стороны, # 1 кажется более простым для старого проекта.

+0

Как DDD входит в картину, когда вы пишете о структуре каталогов? – kayess

+1

Итак, в ваших проектах DDD, как вы организуете структуру кода? Я думаю, вы не хотите, чтобы все строительные блоки были в одном пакете. – slawekpl

+2

В настоящее время, как вы просили, в значительной степени основанное на мнениях, и не уверен, что это поможет будущим посетителям, так как все структуры моих проектов разные. Основное различие заключается в том, что каждый проект _driven_ в разных случаях использования бизнеса, которые являются пространством решений в коде, поэтому я пытаюсь организовать их в соответствии с вездесущим языком, который определяется силой поддоменов и ограниченным контекстом. Я не могу давать хорошие советы и «лучшие практики», так как их не существует. Просто делайте это, так как он соответствует вам и вашей команде, чтобы помочь развитию цикла быть таким же быстрым и эффективным, каким он может помочь. – kayess

ответ

1

Соответственно заказать ddd in php вы можете создавать модули, и в этом случае он будет выглядеть так:

└──src 
    ├── Application 
    ├── Domain 
    │ └── Model 
    │  ├ Account 
    │  ├ Client 
    │  └ Transfer 
    └── Infrastructure 

Но, если учесть, для создания microservices в функции (в случае, если ваш проект действительно огромен) вам может следовать вашей опции # 1, потому что будет легче разделить их на отдельные проекты.

Смежные вопросы