知识体驱动设计

知识体系驱动设计

　　如何指导你的设计，在DDD看来是领域知识驱动，但是比起DDD更提升一层的理念，应该是知识体驱动设计。

• 第一件事，对领域进行充分的理解，其实统一语言就是为了帮助软件开发软件去理解知识的，本质上是一种软件开发者获取知识的交流手段
• 第二件事，是对问题本质的思考，对问题本质的思考，意味你需要看透你所面临的软件开发是什么问题。
  • 如果你只是一个外包仔，那么你不需要思考太多不能归你掌控的事情，能if就if；
  • 问题是否具备逻辑特性，具有逻辑性，可以推理的特点，是掌控万变不离其宗的核心，也是本质复杂度的核心；
  • 问题本身具有多少长期内不容易变特性，多少抽象特性，是否有去建立模型的价值；
• 第三件事，是最痛苦的阶段，根据你对问题的思考，建立一个知识体系，用该体系去解析问题，这一步也称之为建模，但比起软件建模，更多的是思维上的建模，在内心/大脑成立一套模型出来；
第四件事，代码实现，其实内存和代码都是丑陋的，他们都受技术影响，因此DDD的domain其实也不纯粹，只要知识体系是完备的，这个时候，各种具体的开发工作，都应该围绕着这个知识体系去进行，考虑下面几点可以让你更加清晰明白什么是知识体系驱动设计。
• 如何用GO和JS去实现DDD呢？
• 能不能理解线程和过程的区别呢？他们在知识体系中起到什么作用呢？
• 第四件事，通常第三件事可能伴随模型突破，但是软件大部分是长期迭代才能沉淀出越加稳定和完善的知识体系，所以问题生命周期越长，就需要继续演进知识体系。

知识本质突破模型

　　模型突破是很重要的事情，它体现了知识的进一步提炼。知识的突破，一个简单的方式就是在众多概念中，挖掘中对解决问题内聚的概念，并显式它，封装它。

　　举个例子1：一个流程的某一部分的协调进行需要预约，如果这个预约和完成这个预约对流程有影响，那么可以把预约这个领域概念刻画出来。并且单独状态化（也就是不需要其他因子来判断当前流程是否正在预约或者是否完成预约，而是全部依赖这个预约的状态）。然后围绕这个预约实体，做相关的业务操作；

　　举个例子2：命令模式的引入，这里是把命令显式化；