Thinking

架构思考

最近阅读《架构整洁之道》，书中表示架构本质是如何让人更好的维护系统。系统的价值分为两面，一面是系统功能本身的价值，另一面是系统能够继续低成本维护快速响应新需求的价值。设计原则、设计模式都是前人总结出来可以实现第二价值的方式。但是这些方式大多都倾向于技术本身的可维护性。DDD是我见过第一个把业务、领域加入进来的。我认为这是软件发展中的必然。

没有热情的工程喜欢把功能价值做完，然后让系统看上去有价值。有热情的工程师却总是喜欢过度设计。对于有热情的我来说如何克制过度设计带来的成就感或许也是一个挑战

DDD在项目中的价值

这段时间阅读《人月神话》的过程中，感受到一个观点，技术的优劣其实是只是一个维度，选择一个技术的时候需要分析当前情况下，该技术是否能解决当前的痛点，并且综合其带来的影响。这促使我思考，DDD到达能解决什么问题。我个人目前认为，最重要的点在于，DDD的思维和代码结构，将复杂的问题分离，使其变成简单易于维护的相对独立的模块——业务领域逻辑与技术分离、业务流程与领域能力分离。接口层与基础设施层专注于纯粹的技术问题，领域层专注于能力构建，应用层专注于基于领域能力的业务流程搭建，他们之间暴露接口隐藏实现。这很好的解决了业务系统中业务多变性与技术复杂性之间的冲突，提供了高效的可复用性。

业务系统的复杂性

业务系统的复杂性来源于两个方面，第一个是业务的多变与不可预测，第二个是支撑业务的复杂性技术。实际业务是多变而简单的，最复杂的业务只不过与对数据的增删查改，技术是极度复杂但却稳定的。当一个简单的查询语句碰上百万并发会变的非常困难，所以分离业务与技术的实现是十分必要的。保持业务不受复杂技术的入侵可以更好的应对业务的不可预测的幻化。而对于技术则可以利用其稳定的特点进行封装。

面向对象

今天看到一篇推文描述面对复杂业务的不可预测性，他们总是迭代一个1.0版本，等待1.0无法维护了，又重构了2.0然后周而复始，最终他们的解决方案是DDD。看到这里其实我想说，他们忽略了最重要最基本的面向对象，DDD只是面向对象的一种实践，只是在引入DDD的过程中恰好引入面向对象思想而已。对于复杂不可预测的业务，最好设计一个足够抽象的模型，然后通过这个模型扩展出当前业务本身，这样将来如果出现什么变化你也可以以同样的方式扩展出未来的业务，这样你需要把握的就是抽象到什么程度，比如行程的交易系统实际就是共享交易平台的继承了。面向对象的体现不仅仅在代码中，也可以在系统架构中。

业务中的静态条件

今天思考一个不可预测性业务的持续迭代问题。比如一开始设计一个逻辑，如果是在自营业务购买商品，就免去用户确认收货的逻辑，但是后面业务场景变了自营也需要确认收货，这个时候会有一个新的规则，如自营是第三方快递送货的时候。但是实际上去分析这个场景会发现是否需要确认，业务本质是依赖与送货快递是否可靠，这个层面的关系相比自营非自营更稳定，寻找业务中隐藏的稳定关系代替表面上不稳定的关系，业务的可扩展性更强。往往越稳定的关系越趋于业务的本质。另外一提我发现使用DDD可以更容易发现这种隐藏的关系，因为他们了两个都在分析业务的本质。

四层结构思考

思考了一下DDD的四层架构的职责划分。我觉得对于一个业务为中心的应用，我们第一步关心的是做了什么业务，然后是这个业务执行的时候对领域模型做了什么修改，顺带会关心一下有没有什么下游依赖。那些交互体验的优化丢给“用户接口层”处理好就行“应用层”更加存粹处理业务流程，领域能力交给“领域层”，技术类的基础设施在“基础设施层”全部处理好就行，外部领域如果有模型转换应该在“基础设施层”处理好，因为本领域业务其实不关心这些技术性接口的字段转换，只有在具体要处理一个接口的时候才会打开查看，所以不要让他们参与到业务代码中去。设计一个更存粹对你自己本领域更友好的领域模型，总之业务已经够复杂了，不要再让技术和团队协作中的差异或者系统之间的技术性差异来凑热闹了。

DDD使用思考

这几天推进公司的DDD优化，一直觉得现在使用方式有问题，但是一直找不到最根本的问题，在考虑代码结构、设计思维、领域模型各种的不合理之处后得出结论，最根本的问题在于没有围绕着领域模型开发代码，业务中台在进行组件化后，很容易每个组件自己为中心，忽略了领域，如果以组件围绕领域能力来拆分业务流程的方式进行后，一切都变得豁然开朗。