通过《多维度规划业务架构》，我们获得了由业务领域-业务组件-业务服务三个层次组成的业务架构。虽然是架构，但其本质仍然属于问题空间，其目的在于真实地探索问题空间，了解我们要解决什么样的问题。我们用到“分解”的方法，并非在解决问题，而是希望通过横向分层与纵向切分让问题空间变得更小，降低业务复杂度罢了。
这种分解层次体现为：
领域驱动进行的业务分解，既是对问题空间的探索，又自然地暗合确定解决方案的思路。由于有清晰的边界存在，这一做法并未混淆问题空间与解空间，却天然地搭建了一种映射方法，使得我们能够以较小成本将业务架构映射为IT架构中的应用架构。
在我们的数据平台产品中，为了简化开发，对Flink做了一层封装，定义了Job和Flow的抽象。一个Job其实就是Flink的一个作业，每个Job可以定义多个Flow，一个Flow可以理解为是Flink的一个DataStream，利用Job传递的StreamExecutionEnvironment可以在Flow中添加包括Source与Sink的多个算子。
Job与Flow之间的关系可以利用自定义的@JobFlow注解进行配置，如此就可以在执行抽象的AbstractJob的run()方法时，利用反射获得该Job下的所有Flow，遍历执行每个Flow的run()方法。在Flow的run()方法中，才会真正根据StreamExecutionEnvironment执行多个算子。
Flink为了保证计算的稳定性，提供了不同的重启策略。例如，当我们将重启策略设置为失败率（failure-rate）时，如果执行的任务出错次数达到了失败率配置的要求，Flink的Worker节点的TaskManager就会重启。如果超过重启次数，Task Manager就会停止运行。
不出意外，《解构领域驱动设计》再次延期，完全符合一般软件开发的惯例。
我来汇报一下本书临近出版的一条时间线。
5月31日，出版社编辑刘雅思同学告知我本书正式申领到书号，标志着本书正式发稿完毕。这个流程是必走的，否则就别想通过正规出版社出版了。之后的流程就是排版。 因为书的内容非常多，排版花费了不少时间。
领域驱动设计的社区主流声音是划分问题空间（Problem Space）与解空间（Solution Space）。整个问题空间实际上就是团队开发的目标系统对应的领域，这实际上也是业务架构要描述的目标。领域驱动设计解决大规模问题空间的方法或模式是引入子领域（Subdomain）。
根据价值高低的不同，子领域分为核心子领域、支撑子领域和通用子领域。若将其引入到业务架构，似乎可以根据价值高低建立不同的服务层，例如：
不同的层次代表了复用的粒度和水平。基础服务层因为与领域无关，它复用的范围更广泛，对应为业务架构中的支撑业务（支撑部门提供的职能），如财务体系、人力资源体系、行政体系、采购体系等。原则上，任何企业都需要这些支撑业务，而与企业从事的领域方向无关。引入领域驱动设计的概念，我将其纳入到通用子领域的范畴。
DDD的作用范围主要还是针对系统级的分析、架构与设计，在更高的层面上，即将问题空间扩大到超过系统范围，变成企业或组织范围之后，DDD的模式就显得捉襟见肘了。此时，可以考虑引入企业架构的思想，尤其是业务架构的内容，给了DDD很好的补充，又或者说，将企业架构与DDD融合起来，就能真正串联起战略和战术设计了。
为什么在传统企业中，DDD开始得到了许多企业的追捧？不仅仅是微服务的原因，就我个人不成熟的判断，应该是数字化转型开始倒逼着传统企业的IT部门开始接纳了DDD这一方法体系。