身处产业互联网掀起数字化转型浪潮的时代，日益复杂的业务不断扩展迭代，对软件系统不断地提出新的挑战，因此领域驱动重新出现在人们的视野中。现有的系统在长期迭代过程中难免会出现各种各样的边界混乱、架构冗余、开发效率低下问题，而面向业务高效迭代的落地架构是开发人员持续追求的目标。本文旨在介绍DDD领域驱动如何在复杂业务进行设计落地以及技术代码落地，提供领域驱动的设计思路与实施经验干货。
一、系统背景.系统简介每日优鲜定位是一个面向零售云的社区零售线上综合超市，公司主要将业务场景分成人、货、仓、配、店，而目前门店就是核心的五大场景之一，每日优鲜在生鲜行业领先优势就是靠着前置仓的业务模式突出重围的，因此门店承担着履约到用户中间的关键链路，以及一线作业人员的效率支撑，门店技术面临的挑战是，面对C端实时单量的业务场景下，如何为用户提供优质安全的商品，为一线作业人员提供高效且稳定的系统。门店作业系统，是前置仓门店的店内商品管理、作业管理，核心能力是门店货物的发货、收货、店内流转，在每日优鲜供应链和履约体系中承上启下，如下图所示，是订单履约，采购补货等业务场景的核心流程。系统定义：门店系统=门店作业（人员作业+机器作业）+门店策略（店内策略+店间策略）.门店.年，随着每日优鲜的正式创立，前置仓商业模式的试跑成功，线下的人工作业没有任何的系统化记录，导致门店作业效率低下无法被监管，优鲜采购了一套集合大仓和门店一体的仓储作业系统。因为大仓和门店是每日优鲜供应链体系下的重要的两个节点，作业有对半的功能相似度，为了使得业务高效快速运转，大仓和门店共用同一套系统架构。当时整个每日优鲜的业务架构是全国划分多个大仓，每个大仓辐射周边的门店，因此大仓和门店之间是固定的一对多的业务关系。使命特征门店.0的系统使命是从0到，支持每日优鲜的起步，作为一个初步的仓储系统，支撑着每日优鲜早期的业务扩张。核心系统特征是大仓和门店耦合，线下为主，系统为辅，体现在更多的业务功能呈现在PC端，对业务来说是系统更多做为已经线下作业完成后的系统操作记账功能使用。业务模式最初期门店系统在整个每日优鲜的内部业务侧重点在于履约的经营流转过程，用户在平台下单，门店收到订单后线下打印出来，拣货人员按照打印的面单去线下实际的拣货，并且将打包完成的货物交付给骑手，完成订单的作业周转，这时候系统发挥的功能相对单薄，门店.0的系统上只有门店当前商品的总库存数量，具体陈列排布拣货流程完全靠线下把控，因此门店系统.0的核心价值更多的是对全门店进销存的线上记账系统化。技术架构门店.0的技术架构是一套js搭建的后端框架体系，犀牛js框架将js语言转化成java字节码从而运行在JVM虚拟机上，采用mysql主从分离，dis作为通用存储、分布式锁和队列缓存，通用存储为了提升交互性能，分布式锁用来防止数据动作并发，队列缓存则是为了缓和上游C端订单的大量冲击B端的系统并发处理量。由于系统的设计限制，每一个大仓和其辐射的几百个门店同用一套独立的js系统，这样做的优点是能够快速迭代开发，维护便捷，并且减缓了数据性能的压力。暴露问题）性能干扰因为门店.0系统的技术架构是一个大型的单体服务，其虽然能带来迅速迭代开发的优势，同时它的缺点十分突出，单个系统容量有限，接口性能受限制，并且由于门店和大仓在同一套系统中，大仓的业务人员操作会直接影响到门店对应的人员作业性能，二者互相干扰耦合严重。）扩展成本门店.0系统的另一个重点问题就是扩展成本极高，由于历史系统架构原因，系统使用到了很多非标化的组件和系统功能，重新部署搭建一套系统的成本一周左右。随着门店数量的不断增加，大仓辐射的范围和补货运力有限，业务上会扩张新开大仓，在现有的体系下大仓和门店需要申请资源新建部署，耗费运维和技术人力成本较高。随着每日优鲜的扩张，在不同地区线下新业务扩展，尤其是每日一淘和便利购业务的扩张，门店.0系统从最初的套快速扩展到8套主商城系统，套便利购系统。除此之外，一旦门店由于业务原因调整补货大仓，就意味着这个门店从账号到数据需要从一套系统彻底迁移到另一套系统，需要对每日优鲜C端B端整体全链路刷数据调整。因此门店.0系统的运营维护成本很高，利用效率却很低。.门店.0门店.0系统起步于08年下半年，当时随着每日优鲜业务的快速扩展，大仓和门店的数量在不断扩张迭代，原有的.0系统不足以支撑业务发展，急需进行突破改善，尤其是公司将核心业务重心放在了前置仓的经营，因此作为前置仓对应的系统需要跟随着业务的迭代扩展启动进化，在物流负责人的带领下开展积极调研分析，重新对门店系统进行规划，从而门店.0系统开展设计落地，与大仓系统进行切割，彻底的独立解耦，并且根据业务的升级，从大的单体服务变成更适合团队协作的微服务架构。使命特征门店.0的系统使命是支撑门店扩张和大猩猩战略，门店扩张是因为业务经营范围在不断壮大，大猩猩战略则是对门店精细化运营，对门店的库存作业进行统一规范化的线上运营。其系统特征是门店系统独立解耦，核心业务功能线上数字化，体现在系统流程上是门店全量推广手持PDA设备，为即时性作业服务，脱离线下纸质作业，使用PDA设备进行线上化作业指引，通过线上系统去驱动线下作业，而不再是线下作业驱动线上系统的模式。业务升级门店.0系统针对核心业务链路，进行了全流程线上化的功能设计，使得系统充分发挥线上数字化的转型功效。门店内的库区库位库存进行线上化映射，通过系统就可以清晰的知道门店的线下排列和当前真实库存数量情况。升级后的订单作业流程，门店.0系统从交易侧接收订单后，按照订单配送时间在合理的时间自动进行订单的库存分配，自动推送订单给门店内的拣货人员，拣货人员通过手持PDA领取订单开始作业，并且不再依靠线下的记忆去翻找库存，而是通过PDA手持的库位指引去相应的物理位置去拿取对应的商品，从而大大提高了门店内作业人员的拣货效率，并且如果当前系统库存不足也能提前告知提醒拣货人员进行缺品处理。技术架构随着门店的业务复杂度升级，对应的系统复杂度随即而来，门店技术的团队规模也在扩大，单体服务不再适用于团队间的合作维护，因此门店.0中进行微服务架构摸索。当时微服务架构主流的思想是量级考虑，就近原则。比如对门店系统来说，订单和补货是核心业务流程，所以订单和补货独立拆分了微服务；其次考虑业务相似度，包材和订单流程相似度较高，就划入订单微服务；剩下的部分，店内其他作业相关，用户相关，报表相关，库存查询相关，业务上不关联独立成微服务；对优鲜系统间交互逻辑独立出来划分成对外微服务，仅承担转发功能；所有业务的定时任务拆分成统一的任务微服务；因此，整个门店.0体系划分下来，拆成了6个存在耦合的微服务架构。门店.0系统的技术架构是基于SpringCloud的后端框架体系，数据库依然使用mysql主从分离，但是因为数据量和性能原因根据仓组做了mysql分库分表，同时引入了mysql的分区功能进一步提高性能，dis更多的作为缓存和分布式锁应用，引入rocketMQ作为异步驱动解耦系统间交互，ElasticJob作为定时任务控制流转和闭环。虽然上层应用做了微服务拆分，由于库存和业务单据需要事务保障，并且各个服务都直接依赖基础数据，因此通用数据基础数据和库存相关数据库表在同一个jar包内被各个服务引用，从而能够使得基础数据的查询直接走数据库表调用，并且每个服务都能与库存保持事务。门店.0系统的代码架构层级采用的经典的MVC，拆分成三层controller,service,dao，虽然是三层的结构，但其实controller和dao层非常轻薄，绝大部分功能全部集中在service层，导致service层臃肿，内部存在多层级依赖，模块边界模糊相互耦合，如下图所示：暴露问题）数据耦合门店.0系统在机器上按照业务应用拆成了多个独立的微服务，然而基于门店的业务特性，门店业务大多数都基于库存基础上，导致业务系统和库存有着事务一致性要求，因此在技术架构上各个微服务之间提取出了一个公用jar包，内容包含库存和基础数据相关的dao层；另一个问题是只有机器拆分开了，各个业务还是公用数据库，仅仅是按照门店所属区域进行分库分表，每个库中包含所有的业务库表，这就造成了微服务独立的不够彻底，仅仅在机器层面达成隔离，数据层耦合严重，并不符合真正的微服务思想。）性能瓶颈另一个问题是系统过度拆分，领域划分不合理，导致门店系统冗余，机器负载不均衡，分库不合理，数据负载不均，高负载压力大，低负载资源浪费，整体机器和数据库成本高。由于门店.0系统按照区域维度进行分库分表，一些热点区域由于单量较高，最大单表W数据，线上经常会出现慢查询；而且当前大部分业务单据的流转强依赖异步任务调度，这就导致定时任务在线上数据库持续轮询执行，会导致大量慢查询。另一方面任务串行吞吐量有限，过度并行mysql性能压力受限，这就导致一些量级较大的流转效率成为门店的系统的性能瓶颈，在现有体系下难以提升。同时强依赖任务带来的风险极高，一旦任务出了问题业务流程就会严重阻塞。）迭代效率随着每日优鲜业务的扩张，门店.0系统持续在原基础做加法，不断增加迭代功能，当时的技术和业务侧更多
