我的体会是，对于企业微信公众号开发来说，技术真的非常重要。 很多企业微信公众号开发组织，在项目或产品的开发过程中，不重视领域模型，这导致他们无法有效地积累自己的知识。在第10章中，我们会讨论知识资产的话题。

当领域模型变得混乱的时候（这种情况太常见了，我们总是可以看到：软件开发人员会根据需要任意修改模型；或者，由于建模不当，在查找一个信息时要使用10个以上的对象关系），软件实现也变得混乱了。 如果企业微信公众号开发实现被建立在随意变化的模型上，它们就不可能成为长期有价值的知识。在这种情况下，软件开发就像被挟持在一艘失去控制的航船上，在一条颠簸的航线上渐行渐远。场景故事点评：孔如之对于领域模型是非常重视的。他经过深思熟虑后，抛弃了核心系统的数据模型，而使用了ACORD标准作为领域模型。关于这一点，我们可以去看他和林峰的一段对话。 

孔如之认为，标准化永远是工作的方向。这个想法是正确的。另外，使用统一的领域模型也是他对于领域模型的基本认识。在工作中，这些想法已经影响到了林峰，并且被林峰接受了。 于伦并没有认识到这一点，他和林峰为此曾经有过一次尖锐的冲突。作为决策者，他使用了用ID做参数的方案，并且声称对此负责。

 我们通过领域模型来对客观事物的信息进行数学抽象。有时，我们还会从不同的角度对抽象进行再次抽象。例如，计算过程的结构是针对领域中具体行为的抽象，而计算模型则是对计算过程的结构进行的再次抽象。与领域模型（包含数据结构和计算过程的结构）不同，计算模型几乎超出了数学的范畴，它可以说是“数学的抽象”。迄今为止，很多计算模型都没有数学上的表达。我们看到的计算模型常常是一些约束和规则，例如，企业微信公众号开发中分布式开发技术的应用解决模块管理的问题。当然，我们也可以用数学来表达计算模型，并在“数学的抽象”这个级别上进行计算。不过，要完成这个任务，我们需要更多的符号和定义。   

领域模型中的行为对象定义了计算过程的结构，但是没有给出计算的具体实现。例如，很多领域模型软件定义了保险业务中的保费计算，但是往往没有给出保费计算的具体实现。一般来说，要完成一个计算，除了计算过程的结构之外，还有两件事情需要考虑：一个是计算的逻辑实现，一个是计算的物理实现。