DDD的架构规划与决策
大家好，我是范钢老师。一转眼，我们对DDD的探讨已经颠末好几个系列了。在第一个系列《DDD你真的理解清楚了吗》内里，我们一起探讨了DDD学习中那些困惑多年、艰涩难懂的知识，资助大家答疑解惑。这些知识包罗：
- 什么是“值对象”？它与“实体”有什么区别？
- 范畴驱动设计到底应该是用充血模子？还是贫血模子？
- 什么是“聚合”关系？在实际项目中该怎样使用“聚合”？
- 限界上下文该怎样分别？如许分别有何意义与价值？
- 怎样运用“统一语言建模”，与客户沟通业务需求？
- 事件风暴会议该怎样召开？又怎么形成范畴模子？
- DDD怎样在灵敏团队与非灵敏团队中去实践？
接着，在第二个系列《DDD该怎么去落地实践》中，我们更加深入地探讨了，要将DDD落地到实际项目中，又该怎样设计？这里的关键在于，怎样将范畴建模中设计的范畴模子，清楚而完整地落地到设计编码中：
- 范畴模子中有哪些对象，步伐设计就有哪些范畴对象
- 范畴模子中这些对象有哪些方法，步伐设计中都要落地实现这些方法
- 范畴模子中这些对象之间有什么关系，在步伐设计中要完整地把这些关系都表达出来。
因此，DDD落地实践的关键起首在于“关系”的实现，它们包罗“一对一”、“多对一”、“一对多”、“多对多”关系，以及“继续”关系、“聚合”关系。对于上层的业务开辟来说，他们只必要按照范畴模子与业务需求，将这些关系落实到范畴对象、服务对象与DSL的设置，业务代码就实现了。接着，通过底层平台，去实现“通用堆栈”、“通用工厂”的功能，从前端将Json转变成范畴对象，向后台持久化范畴对象到数据库。通过如许的设计，将上层的业务代码，与底层的技术框架进行分离，一方面让业务的变动与技术的更迭，可以相互独立地去维护变动，低沉了系统层次的复杂度；另一方面，则使得业务代码减少，让日后的变动，更加容易地随着范畴模子而变动，低沉了代码维护的成本。这是“整齐架构”的设计头脑。
有了以上这些思路，还必要站在架构师的角度去思考，我们为什么要使用DDD？什么时候该使用？而什么时候不实用？显然，DDD也不是“银弹”，并不实用所有的场景。DDD更加实用于实现增删改的操作，包罗“用户下单”的流程、“用户档案”的管理、“商品库存”的操作，等等。然而，DDD不适合各种查询、分析、统计等操作。因此，在落地DDD时，常常采用CQRS（命令与查询职责分离）的架构，增删改是一套体系，查询分析则是另一套体系，这在我前面的文章中已经探讨过了。
除此之外，DDD是软件核心复杂性的解决之道，所以DDD更实用于业务复杂、规模庞大的系统，而不实用简单的系统。理解这一点非常重要。很多团队在刚开始实践DDD的时候，常常选用比较简单的新项目来练手。然而，新项目其实并不实用于DDD。它起首是业务简单，并不能发挥出DDD的上风。同时，新项目往往时间比较紧急，必要快速开辟、快速上线。如许的特点，DDD的上风发挥不出来，反而让DDD的劣势显露无余，其实并不合适。
实际上，DDD更实用的是那些颠末多年的维护，业务开始变得越来越复杂而难于维护的系统。它们随着业务的变动，业务理解起来越来越困难，就越来越难于变动维护，从而使得设计质量下降，维护成本上升。如许的系统，更必要通过对业务的梳理，通过范畴模子的抽象，来指导业务的变动与代码的更改。然而，很多的老系统，在设计之初没有采用DDD，现在要转型成DDD，一定是有一定难度的。那么，老系统的DDD转型该怎么做呢？
在TOGAF的架构设计方法论中，提出了“目的架构”、“基线架构”与“过渡架构”的设计头脑。目的架构就是我们通过转型必要达到的目的，这里就是DDD转型的架构设计；基线架构就是目前的状态，即当前采用的是什么架构；过渡架构则是怎样通过一些中间过渡的步调，一步一步从基线架构转型成目的架构。通过如许的设计头脑，就为老系统的DDD转型提供了很好的设计思路。
起首，我们必要通过梳理形成目的架构，也就是通过规划，未来期望达到的目的。现在我们的目的是通过DDD的转型，对原有老系统的业务进行梳理，将已往没有绘制的范畴模子都绘制出来。然后，基于如许的范畴模子，形成未来的系统设计。为了让现有的设计不消影响未来的正确设计，我建议大家暂时忘掉当前的设计，完全基于业务去梳理并形成范畴模子。然后再将范畴模子与当前的设计进行比较，就会发现当前设计中许多的设计问题，这些都是必要解决的问题。
有了基于范畴的业务梳理，就形成了目的架构。接着，再将目的架构与当前系统的基线架构进行比较，订定架构转型的路线图。起首，我们希望目的架构与基线架构不要差异太大，如许改造起来就比较容易，风险比较低。这必要在设计目的架构时，通过架构选型，有一定的折中。同时，我们也可以在目的架构与基线架构中间，设计一些过渡架构，一小步一小步地逐步进行改造，把长周期的改造变成很多个短周期的改造。
譬如，已往那个老系统是采用的SSH（Struts+Spring+Hibernate）或者SSM（SpringMVC+Spring+MyBatis）架构，那么代码就分为MVC, BUS, DAO三个层次。这时，DDD转型的目的架构也采用如许的分层结构，改作育比较容易。然而，在老系统中，有太多的业务校验、业务操作在MVC层的Controller中实现的，那么现在就必要通过重构，将这些代码逐渐迁徙到BUS层的Service中。通过如许的改造，Controller中的代码就越来越少，末了变得与业务无关，只与MVC技术框架有关。如许，今后无论怎样变动MVC技术框架，都变得比较容易。
别的，DDD在持久化保存数据库时，必要堆栈与工厂，而当前老系统的保存是通过编写DAO的代码实现的。因此，在订定DDD的目的架构时，把堆栈与工厂设计成是DAO的接口实现，使得从基线架构过渡到目的架构更加容易。如许的设计，就可以在已往DAO接口不变的情况下，将已往DAO的实现，切换成堆栈与工厂的实现，就实现了从已往的架构向DDD架构的转型。在此基础上进行规划，一个模块一个模块地逐步改造，就可以通过多个过渡架构实现逐步的DDD改造。
接着，已往的基线架构，每个模块都要写一个DAO，编码比较繁琐，倒霉于日后的维护变动。再通过重构，逐渐从所有的DAO中抽取出通用DAO，从所有堆栈和工厂中抽取出通用的堆栈和工厂。然后，将这些通用的DAO、堆栈和工厂下沉到底层平台上，那么上层的业务开辟就不必要编写DAO、堆栈和工厂。业务开辟职员只必要根据范畴模子编写范畴对象、服务与DSL，怎样持久化与上层无关。那么，上层的业务编码就与底层的数据库持久化解耦。今后，我们可以采用差别范例的数据库、缓存、消息队列，但它们的设计都与业务代码无关。如许，数据持久化技术的更迭变得容易，今后乃至可以转型成NewSQL、NoSQL数据库，乃至是大数据平台。记取，真正的高手往往不必要选型，而是全部支持，然后在日后的运维中，根据必要灵活选择。
所以，DDD的转型不是面向那些简单的新项目，而是更加务实地面向那些公司核心、颠末多年维护、维护起来越来越困难的老项目，这是DDD落地真正的深水区。这部分的落地确实难，不是一朝一夕能完成的，却是真正发挥DDD的上风，解决企业痛点与难题的地方。通过DDD的梳理先形成目的架构，在与当前的基线架构进行比对，订定过渡架构，规划DDD转型路线图，逐步改造。通过如许的思路，就可以将DDD落地到那些复杂的老项目中，把DDD真正地运用起来，把它的上风发挥出来。
假如对以上内容感觉有用，欢迎关注、点赞、转发！
下一期，我们谈谈DDD架构设计的灵魂——整齐架构。
（待续）
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
