重构代码架构使具有良好扩展性（DDD）学习和思考

背景

重构背景

以前觉得大部分公司都需要高并发、高可用，这些才是主要发展方向。项目已经上线一年了，最近因业务原因需要快速迭代上线，几个开发一起接入了一个WMS系统，并将流程并入我们现有流程当中，涉及到计算库存、库龄、资方借贷等很多节点。因为比较急，随即将新的业务代码穿插进了原有的业务逻辑中进行处理，突然感觉代码的可维护性变的比较差，虽说有业务需求变更的原因，但代码还是要写下去的。根据公司业务规划，后续自己的系统将处于上层，上面要对接电商和ERP系统，下面要对接多仓库WMS，物流TMS，并且还要有自己的业务流程。现在的代码规划，可能会使得系统逐渐变得复杂，所以考虑要重新规划一下。

重构方向

清晰系统

具体开发的内容是跟着业务的不停发展进行演变的。

• 现确定了系统开发目的是为上游商城业务提供API服务，并对接下游仓库，通知发货、入库等操作。那么自己的系统应该处于中间层。
• 系统中存在对业务不清晰时，设计的老旧方案。重构时，明确每一个服务或模块的边界，就算需要进行额外的开发，也要将系统进行统一。尽量简化每个部分的逻辑。

简而言之：先明确系统定位。

重构原则

• 设计上，架构先行，功能次之；
• 实现上，功能优先，架构次之；
• 业务重的先放放，解决眼前的问题，渐进开发；

敏捷开发每周都会进行一次交付，但系统还需要提供对应的服务，并保证需求的更新。如果强行要求进行规范的代码开发，可能耽误开发进度。但设计上如果没有进行好对应的规划，可能很快就需要再进行一次重构。对于现有系统的重构，不能急于一时，毕竟一坨屎能跑，那也是好的。但开发现在就要维护的地方，要渐进式的完成重构。

重构方案

DDD的选择

现在微服务的声音越来越大，那么是不是应该选择直接将业务拆用微服务进行实现呢？大部分的业务，单体应用其实是完全能够解决问题的，不过在一块业务复杂之后，简单的MVC模式，因为产品和开发对业务理解的不同，可能出现改A错B，修B错C的问题。但应该可以通过更好的设计模式，或者异步任务等将逻辑进行简化，达到方便维护的目的。相比之下，开始就以业务领域为主的DDD可能是更好的选择。
但市面上初级的Java好找，会DDD设计的程序员相比之下就不好招了。

参考内容：
领域驱动设计实践
领域驱动设计-Eric Evans

思维的转变

在领域驱动设计中，数据并不是第一位的，而是先要进行领域内容的区分。

开发方案

涉及业务内容，枯燥且描述不了。

实际开发

开发过程中，逐渐对DDD的理解。

• 如果你对业务或者编码有你的习惯或理解，开发前需要先规划好相应的上下文。
  • 初次开发DDD时，两个相似或相关的业务，可能因为你对结构判断的不同，会浪费大量的时间在调整代码层级上。
• repo独立出来提供数据库访问的好处
  • SOA 设计喜欢给服务分层(如Service Layers模式)。我们常常见到一个Entity服务层的设计，美其名曰Data Access Layer。这种设计要求所有的服务都通过这个Entity服务层来获取数据。这种设计非常不灵活，比如每次数据层的改动都可能影响到所有业务层的服务。而每个微服务通常有它自己独立的data store。我们在拆分数据库时可以适当的做些去范式化(denormalization)，让它不需要依赖其他服务的数据。
    引用：微服务架构讲解