【发布时间】:2016-10-25 07:16:30
【问题描述】:
我正在致力于改进项目结构的遗留项目。我的问题是我应该如何组织代码结构。我看到两个选项:
#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 似乎更容易实现。
【问题讨论】:
-
当你写目录结构时,DDD是如何出现的?
-
好的,那么在您的 DDD 项目中,您如何组织代码结构?我猜您不想将所有构建块都放在一个包中
-
嗯,目前您的提问方式几乎是基于意见的,并且不确定它是否会对未来的访问者有所帮助,因为我所有的项目结构都不同。基本区别在于每个项目由不同的业务用例驱动,这是代码中的解决方案空间,因此我尝试根据由子域的力量驱动的无处不在的语言来组织它们和有界上下文。我不能给出好的建议和“最佳实践”,因为这些都不存在。只需这样做,因为它符合您和您的团队的要求,以帮助开发周期尽可能快速和有效。
-
我没有看到任何与接口相关的内容。接口对于解耦组件至关重要。
标签: architecture domain-driven-design directory-structure legacy