组织我的基于 DDD 的 Web 应用程序的目录结构？
我开始放弃创建 Web 应用程序的常规 MVC 方式，转而研究领域驱动设计 - DDD。
从仅拥有 Models，我现在拥有 Collections、Entities、DataMappers 和 DataMappers。我的应用程序中要使用的Repositories。当然，完全的分离和模块化，但现在我的目录结构只是一团糟！
由于我过去从未使用过 DDD 应用程序，因此我对如何组织文件结构知之甚少。
下面是合适的目录结构吗？
注意：我使用的是 PHP5，但我认为这个问题与语言无关。
/application
/common
/libraries
/helpers
/temp
/cache
/domain
/collections
/entities
/datamappers
/repositories
/ui
/controllers
/view
I have started to look away from the normal MVC way of creating my web applications and have had a look at Domain Driven Design - DDD.
From having Models alone, I now have Collections, Entities, DataMappers & Repositories in my application to work with. Full-fledged separation and modularity for sure, but now my directory structure is nothing but a complete mess!
As I have never worked with a DDD-application in the past, I have little idea on how to organize my file structure.
Would below be an appropriate directory structure?
Note: I am using PHP5, but I reckon this question to be close to language-agnostic.
/application
/common
/libraries
/helpers
/temp
/cache
/domain
/collections
/entities
/datamappers
/repositories
/ui
/controllers
/view
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为这是有道理的，但是，这会将您的模块分为它们所在的层，而不是它们做什么。例如，在这种结构中，如果您想要一个身份验证和打印模块，您可能会有这样的东西：
在这样的系统中工作后，我可以说一件事，很难保持模块之间的边界相互啮合，只是因为人类在各层中工作，并将各层视为“全部在一起”。仅从组织的角度来看，我真的不喜欢必须打开三个根级目录才能使用特定模块。我们将项目组织到目录中是为了让我们更容易处理，而不是编译器。
如果我再次这样做，我会按层分离一些内容，例如在一个级别上分离 UI 代码，在另一个级别上分离业务代码，然后按其下的模块分离。我想更像是一种混合体，但也许更好。
I would think that makes sense, but, that is going to separate your modules into what layer they are at, rather then what they do. For example, in this structure, if you wanted an Authentication and printing modules, you would have probably something like this:
Having worked in a system like this, I can say for one thing, it gets very hard to keep the boundaries between modules from inter-meshing, just because humans are working in the layers, and thinking of the layers as 'all together'. Just from an organizational standpoint, I don't really like having to have three root level directories open to work with a particular module. We organize projects into directories to make it easier for us to deal with, not the compiler.
If I was doing it again, I would separate some things by layer, say UI code, on one level, and business code on another, but then by module under that. More of a hybrid I suppose, but perhaps better for it.