DDD的片段

 

 

 

   当我们创建一个软件应用时，这个应用的很大一部分并没有直接与领域关联，但它
们是基础设施的一部分或者是为软件本身提供服务的。最好能让应用中的领域部分与其
余部分相比保持尽可能小（而不是和其余部分掺杂在一起），因为一个典型的应用包含
了大量访问数据库、访问文件或网络、用户界面等相关的代码。

 

  在一个面向对象的程序中，用户界面、数据库以及其他支持性代码经常被直接写到
业务对象中。附加的业务逻辑被嵌入到 UI 组件和数据库脚本的行为中。之所以有时候
这样做，原因是这样可以很容易地让事情快速工作起来。

 

   但是，当领域相关的代码被混入到其他层时，要阅读和思考这些代码也变得极其困
难。表面看上去是对 UI 的修改，却变成了对业务逻辑的修改。对业务规则的变更可能
需要谨慎跟踪用户界面代码、数据库代码以及其他程序元素。实现粘连在了一起，模型
驱动对象（model-driven objects）于是变得不再可行。也很难开展自动化测试。对于所
有活动中包含的全部技术和逻辑而言，程序必须保持简单，否则就会变得很难理解。

   因此，将一个复杂的程序划分成多个层。为每一个层开发一个内聚的设计，让每个
层仅依赖于它底下的那些层。遵照标准的架构模式实现与其上面的那些层的低耦合。将
领域模型相关的代码集中到一个层中，把它从用户界面、应用和基础设施代码中隔离开
来。领域对象不必再承担显示自己、保存自己、管理应用任务的职责，而是专注于表达
领域模型。 这会让一个模型逐渐进化得足够丰满、 足够清晰， 以便捕获基本的业务知识，
并且能够正常工作。