DDD设计中BC（bounded context）是解决方案域的核心，其外联子域，内包聚合，是内联外通的关键路径，同时也是微服务的边界，是DDD建模的基础。
DDD建模难点之一是如何快速合理划分BC，有没有好的思路呢？
其实尽管可以通过Events Storm、四色建模、CRC、UseCase等方法划分出一系列的BC，但是过于依赖方法和套路建出来的模型难免“匠气”过重，这些BC从业务的角度看一般只能说是不算差。
如果要划分出一系列恰如其分的BC，不仅需要对行业有深刻理解，还需要更多对业务本质的洞见以及丰富的业内经验。笔者也曾和DDD创始人Eric Evans当面交流过如何划分一个恰当的BC，只记得他当时就非常笃定的回答：by experience。
现在咱们也就按这个by experience的思路看看常见业务中BC是否有迹可循，能否照猫画虎快速划分？
目前碰到的DDD建模的业务中，其实本质一般都是对某些抽象资源的遍历、计算、汇聚等，一般都可以抽象为资源管理、任务管理、算法管理三大BC，这三大BC基本可以涵盖主要业务流程，我们简称其为三板斧，其中：
资源管理
管理系统中的核心资源，一般是业务核心流程中的设备、人员甚至商品在系统中的抽象，重点是资源的分类和表达的数据结构等；主要是存取遍历资源操作。
算法管理
具体如何使用这些资源进行业务流程；主要是计算、汇聚等操作。
任务管理
把资源和算法进行撮合和匹配；主要是调度、跟踪任务执行和事务管理等操作。
再配合用户管理等辅助功能就能覆盖全部业务。当然看业务的复杂程度和规模，这几个BC还可以包含一些子BC，或者算法管理比较简单也可以合并到任务管理里面。
这三板斧基本可以囊括我们常见业务的DDD建模。
比如电商系统，商品就可以应对到资源管理，订单就可以映射到任务管理，计算价格折扣等都可以对应到算法管理。
比如滴滴打货，车辆（司机）、货物相当于资源管理，货单相当于任务管理，距离、价格、司乘匹配如果复杂等相当于算法管理，简单的话就合并到货单管理。
再比如电信产品中对底层硬件抽象成软件系统中的mirror，也都是资源管理、任务管理和算法管理三大部分组成，当然不同的业务场景中要给这三个BC各自起一个恰当的业务名字。
三板斧形式的DDD模型有没有可以快速实现的模式呢？
其实可以参考设计模式中的访问者模式。
访问者模式中：
被访问者
可以对应资源管理，特别是被访问者管理的数据结构（例如组合态的树状套树状结构、图状结构等）比较复杂和数据量巨大的时候，遍历或访问算法会非常复杂（深度、广度、最小路径、邮差算法等），这时就更需要内聚成一个BC；
不用关心如何使用数据和算法，核心是处理好对组合资源的遍历和遍历性能提优。
访问者
相当于算法管理，对每个原子资源进行计算，并对计算结果进行汇聚，不用关心具体数资源的数据结构，核心聚焦在算法和计算性能的提升。
当然，访问者模式特点是算法（访问者）可以方便扩充；被访问者（数据结构）要相对稳定，这样有利于开闭原则的实现。
但是对于一般业务场景来说，都是核心资源数据结构比较稳定，算法变化频率相对较高；
加强版访问者模式
访问者和被访问者之间可以增加一个任务管理进行资源遍历和计算之间的动态匹配和跟踪管理。
一个三板斧+加强版访问者模式的案例：
我们碰到过一个服务集群状态分析检测系统的设计，业务功能是检测大规模集群中服务节点健康度指标，并根据指标进行一系列健康度的计算，并依据健康度指标决策是否进行服务自动弹缩实现缩扩容或限流熔断等举措。
根据我们的三板斧，一次就可以把系统划分为：节点管理（资源管理）、健康度采集分析管理（算法管理）、调度管理（任务管理）三部分，而且这种划分天然就很合理，各块功能和要点、难点都比较内聚。
从业务本身来说，资源情况还是比较复杂的，由服务-》集群-》容器-》指标等复杂树状结构组成，加上总的数据量巨大，而且业务变化频繁，对节点管理的扩展性和遍历性能方面要求较高，如果把节点访问、各种定时器、人工、各种优先级任务调度和各种指标采集分析执行耦合到一块，系统复杂度会急剧上升；
现在节点管理独立出来，仅负责节点遍历操作，复杂度可控。
另外健康度采集分析本身的种类和算法很多，而且会随着业务上线不停的调整和扩展，但指标的数据结构相对比较稳定（非常符合访问者模式应用场景），这样这块核心难点就集中在算法实现的复杂性和性能调优上，而不用关心复杂的节点结构，这样难点就比较内聚。
调度管理是控制采集分析的频度和跟踪各次任务，同时进行事务处理（异常情况下的补采等），本质就是任务管理的内化。
小结：
BC划分三板斧+访问者模式优势：
1、资源数据结构可以独立变化，调整数据结构或遍历算法，只需要修改一处，实现单点变化，功能内聚。
2、算法可以独立修改，多个资源汇聚状态可以保存在访问者中，增加算法只要增加不同的访问者即可，功能内聚。
3、调度周期、优先级和调度方式等只在任务管理维护，同样可以实现单点修改。
以上BC划分三板斧+加强访问者模式，可以快速进行DDD领域建模和代码架构实现，轻量实现功能内聚，单点维护和易于扩展的系统。
