好玩的网站列表

在看博文的时候看到了关于DDD的内容，确实发现在工程上碰到了一些些问题，关于核心领域，关于领域驱动，毕竟技术是为了解决实际问题的，只有在对某个领域有着较深的理解的前提下，才能做出更有利于维护，更容易扩展的软件。

本书想说的就是在大规模工程上，如何来控制整体的复杂性，我们需要有一个良好的领域模型，不仅仅停留在领域的表面，而是要透过表象抓住领域的实质结构，从而为软件开发人员提供他们所需要的支持。

软件的负责性并不仅仅在技术上，而是来自领域本身，用户的活动或业务。这种复杂性我们需要在设计上考虑到的。

领域涉及的前提：

1. 在大多数软件项目当中，主要的焦点应该是领域和领域逻辑
2. 复杂的领域设计应该基于模型

领域驱动设计的实质是消化吸收大量知识，最后产生一个反映深层次领域知识并聚焦于关键概念的模型

1. 让领域模型发挥作用 - 领域驱动开发的基本目标

1.1 几个基本问题

• 什么是模型？
  • 模型是一种简化，是对现实的解释，并把与解决问题密切相关的方面抽象出来，而忽略无关的细节。
  • 模型是为了解决信息超载问题的工具
  • 模型是一种知识形式，它对知识进行有选择的简化和有目的的结构化
• 如何界定领域？
  • 每个软件程序的目的都是为了执行某项活动，或者满足用户的某种需求。用户会将软件程序应用在某个主题区域当中，这个区域就叫做软件的领域。
• 软件的核心是什么？
  • 用户解决领域相关的问题的能力

1.2 如何有效消化知识？

1.2.1 有效建模的要素

• 模型与实现的绑定
  • 在模型与实现之间建立早期连接，在后续的所有迭代当中维护该原型
• 获得一种基于模型的语言
  • 业务和技术上的对应的模型的熟悉，对于名词的意思达成一致
• 开发一个蕴含丰富知识的模型
• 提炼模型 - 保证模型整体结构的精炼

1.2.2 知识消化

在大量信息当中探寻有用的部分，由开发人员和领域专家组成的团队共同协作，收集信息并寻找对信息有意义的简化视图。

在你的架构当中应当本身就有领域的特征，即某部分需要能够清晰的反应商业上的可能需求和可能的拓展。这种东西如果在刚刚开始的时候就能被研究到，那以后就会很方便了。

开发出来的软件是需要能够反应出领域专家的思考方式的，我们用自己的技术来解决他们的问题，用代码构建他们的思维体系。

1.3 语言的交流和使用

• 模型
  • 头脑中形成的与项目有关的概念集合，用术语和关系反映了领域的深层含义。这些术语和关系提供了模型语言的语义
  • 不仅仅限于UML图，需要充分利用各种交流手段，以提高代码本身和测试的沟通能力

1.3.1 模式： Ubiquitous Language

需要一种通用的，共享的团队语言，这种语言应该是时刻进行检验的。语言上的鸿沟，即我们对同样的词语是没有同样的认识的，这就导致了当我们对某个领域不够熟悉的时候，对于各种概念的理解是有很大量的欠缺的。而各类人在工作的时候也很容易为了方便创建小范围达成共识的语言，但是在这个小范围之外是没有人知道和了解这究竟是什么意思的。

• 为什么需要这种公共语言？
  • 将团队的沟通和软件实现紧密联系起来
  • 避免因为对于概念不同理解带来的交流沟通成本陡增的问题
• 词汇表
  • 类名称
  • 主要操作
  • 术语
    • 讨论模型当中已经明确的规则
    • 或者是模型上的高级组织原则
• tips
  • 模型作为语言的中心，确保团队在所有交流活动和代码中坚持使用这种语言
  • 通过尝试不同的表示方法来消除难点，然后重构代码，并对类、方法和模块重新命名，以便与新模型一致。
  • 需要对各种词语，无论是在工程上的，还是在商业上的，都有更好的理解
  • 要认识到Uniquitous Language当中的更改就是对模型的更改。

1.3.2 文档和图

• UML图有用，但是会容易是你陷入细节当中
• 图应该是一种直观的给你综合概念和视角的工具，而不是落于细节当中。
• 设计的重要细节应该在代码当中体现出来

• 书面设计文档
  • 提供稳定和共享的交流
  • 文档应该作为代码和口头交流的补充
• 解释性模型
  • 没有UML 没有类
  • 就是单纯的用图来描述商业上的使用案例

2. 模型驱动设计的构造块 - 阐述核心最佳实践

3. 通过重构加深理解 - 如何将构造块装配为实用的模型

4. 战略设计 - 讨论在复杂系统交互中的情况

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 stone2paul@gmail.com