2

当我输入这个时,我意识到这很难解释。如果它是不可分辨的,我很抱歉。我的最终目标是让有更多经验的人了解我如何构建我的解决方案,并提供关于它是否可接受的设置的反馈。如何使用C#.NET实现DDD 4

我目前管理几个彼此松散相关的小型支持项目。他们都是全面的。我想创建一个统一的INTERNAL-WEB应用程序来管理这些项目。我已经设法将一切概念上分成三个域。运输,外部网络,内部网。从业务角度来看,SHIPPING将WIDGET发送给客户,然后客户连接到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) 

我必须添加额外的项目范围内的地图和反腐败层在不同域之间的通信,但是这是基本的布局。

这是聪明还是愚蠢?

感谢, 格雷格

+2

值得注意的是,DDD更多地与您开发与客户沟通的“无处不在的语言”,而不是实际的编码。 – 2011-02-17 00:07:17

回答

2

您如何配置你的解决方案无关,与DDD,并不会影响你的项目的成功。 糟糕的组织好的代码比组织良好的错误代码要好得多。

项目具有与其相关的生产力和复杂性成本。现在你正在为一些并不重要的细节而烦恼。

更多的项目也等于较慢的编译时间,这增加了上下文转换。尝试阅读一本书并每页停留30秒。

应该为部署或代码共享目的创建新项目。很好的理由包括,如果域名在两个前端之间共享,或者如果你有一个怪异的部署策略(1000台机器),MB仍然很重要。

一旦您简化了新项目的规则,随着代码库的成熟以及新的需求的出现,决策开始自然而然地展开。你基本上是在最后一刻做出实际决定。这很好。当你有功能和代码写入时,不要BUFD!


不确定为什么这个问题被标记为MVC,但MVC代码库相当精简,只有一个主项目。编译速度快,并且很容易导航。