如何使用 C# .NET 4 实现 DDD
当我打字时，我意识到这很难解释。如果难以辨认，我深表歉意。我的最终目标是让有更多经验的人看看我如何构建解决方案，并就其是否是可接受的设置提供反馈。
我目前管理着几个彼此松散相关的小型支持项目。他们都是全面的。我想创建一个统一的INTERNAL-WEB应用程序来管理这些项目。我已经成功地将所有内容在概念上分为三个领域。运输、外部网络、内部网络。从业务角度来看，SHIPPING 将 WIDGET 发送给 CUSTOMER，然后连接到 EXTERNAL-WEB。问题是 SHIPPING 对 WIDGET 和 CUSTOMER 的定义与 EXTERNAL-WEB 定义不同，所以我需要将这两个分开。
经过一番思考，我得出的结论是，在 VS2010 中组织此操作的最佳方法是创建一个解决方案，然后在该解决方案中嵌套多个项目。我正在设想如下的布局。
SOLUTION
---SOLUTION.SHIPPING.Domain (Classes)
---SOLUTION.SHIPPING.Infrastructure (Classes)
---SOLUTION.EXTERNAL-WEB.Domain (Classes)
---SOLUTION.EXTERNAL-WEB.Infrastructure (Classes)
---SOLUTION.INTERNAL-WEB.Domain (Classes)
---SOLUTION.INTERNAL-WEB.Infrastructure (Classes)
---SOLUTION.WebUI (MVC3 Project)
我必须为上下文映射和反腐败层添加额外的项目，以允许域之间的通信，但这是基本布局。
这是聪明还是愚蠢？
谢谢， 格雷格
As I'm typing this, I'm realizing that it's very hard to explain. My apologies if it's indiscernible. My end goal is to have someone with more experience look at how I'm structuring my solution and provide feedback on whether or not it is an acceptable setup.
I currently manage several small support projects that are loosely related to one another. They are all over the board. I want to create a unified INTERNAL-WEB application to manage these projects. I've managed to group everything conceptually into three domains. SHIPPING, EXTERNAL-WEB, INTERNAL-WEB. From a business perspective, SHIPPING sends WIDGETs to CUSTOMERs which then connect to EXTERNAL-WEB. The problem is that SHIPPING's definition of WIDGET and CUSTOMER is different than the EXTERNAL-WEB definition, so I need to break these two apart.
After some thinking, I've come to the conclusion that the best way to organize this in VS2010 is to create a solution and then nest multiple projects within the solution. I'm envisioning a layout like the following.
SOLUTION
---SOLUTION.SHIPPING.Domain (Classes)
---SOLUTION.SHIPPING.Infrastructure (Classes)
---SOLUTION.EXTERNAL-WEB.Domain (Classes)
---SOLUTION.EXTERNAL-WEB.Infrastructure (Classes)
---SOLUTION.INTERNAL-WEB.Domain (Classes)
---SOLUTION.INTERNAL-WEB.Infrastructure (Classes)
---SOLUTION.WebUI (MVC3 Project)
I'll have to add additional projects for context maps and anti-corruption layers to allow communication between domains, but this is the basic layout.
Is this smart or is it stupid?
Thanks,
Greg
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您如何配置解决方案与 DDD 无关，也不会影响项目的成功。 组织得不好的好代码比组织得好的坏代码要好得多。
项目会产生与之相关的生产力和复杂性成本。现在你正在为一些并不重要的细节而苦恼。
更多的项目也意味着更慢的编译时间，这会增加上下文转换。尝试阅读一本书，每页暂停 30 秒。
应出于部署或代码共享目的创建新项目。很好的理由包括域是否在两个前端之间共享，或者如果您有一个巨大的部署策略（数千台机器）并且兆字节仍然很重要。
一旦简化了新项目的规则，随着代码库的成熟和新需求的出现，决策就会开始自然地做出。你本质上是在最后一刻做出实际决定。这很好。当您有功能和代码要编写时，请不要对此进行BUFD！
不知道为什么这个问题被标记为 MVC，但 MVC 代码库非常精简，只有 1 个主项目。编译速度快并且非常容易导航。
How you have configured your solution has nothing to do with DDD and won't effect the success of your project. Good code that is organized badly is much better than bad code that is organized well.
Projects have a productivity and complexity cost associated with them. Right now you are agonizing over details which don't really matter.
More projects also equals slower compile times which increases context shifting. Try reading a book and pausing for 30 seconds every page.
New projects should be created for either deployment or code sharing purposes. Good reasons include if the domain is shared between two front or if you have a monstrous deployment strategy ( 1000s of machines ) and megabytes still matter.
Once you simplify the rules for new projects the decisions start to be made naturally as the codebase matures and new requirements pops up. You are essentially making physical decisions at the last possible moment. This is good. Don't BUFD this when you have features and code to write!
Not sure why this question is tagged MVC but the MVC codebase is pretty lean with only 1 main project. Compiles fast and is really easy to navigate around.