领域驱动设计之代码优先-领域层设计-4 （翻译）

2.4.-  领域层设计的注意事项


  当设计领域子层时，软件架构的主要目标应该是最小化复杂性，把不同的任务分到不用的地方。我们在每个
地方设计的组件都应该针对该特定区域，不应该包含其他区域的相关代码。
  在设计业务层时下面的准则应该考虑到：


-  定义不同种类的领域组件：按照需求实现不同类型的模式总是一个好注意。这会增加代码的可维护性和可
重用性。例如，我们可以定义领域服务类，领域实体类和查询规格契约的组件。最后，甚至可以有工作流类型
的业务流程，虽然我们一般会把调用工作流放在更高的层中留在应用层而不是在领域层。


-  识别领域层的职责：领域层应该用来处理业务规则，转换数据，应用策略和实现业务相关的验证。


-  高内聚设计。组件应该只包含和组件或实体相关的具体的功能点。
 
-  不要把领域层的不同类型的组件混淆：领域层应该用来和表现、数据访问解耦，同时用来简化业务逻辑的
单元测试。最终，这会大幅提高系统的可维护性。


-  重用通用的业务逻辑：为不同类型的客户端（Web，RIA，手机等）应用重用业务逻辑。


-  识别领域层的消费者：这会有助于决定如何暴露业务层。例如，如果表现层会使用传统的Web应用，最好的
选择是直接访问。然而，如果表现层是运行在远程机器上，就需要通过分发服务层来提供领域和应用层。


-  使用抽象来实现解耦的接口：这可以通过接口类型的组件实现，接口的通用定义或共享的抽象，组件依赖于
抽象而不是具体的组件。换句话说，它们不直接依赖于类。这对领域服务尤其重要。


-  避免循环依赖：领域层应该只通过抽象或者是控制反转容器知道相关的底层的细节。然而，它们不应该直接
知道任何高层的细节。


-  领域层和较低层间的解耦：使用抽象/接口，最强大的技术实现解耦是控制反转/依赖注入。


3.- 使用.NET 4.0和解耦工具Unity实现领域层


  这章的目的是展示实现领域层的不同技术，解释使用.NET 4.0架构的技术。


  我们着重了在Visual Studio 2010的层图中的领域层。