在单体应用时代，我们是非常重视数据库的设计的，因为只有正在运行的数据库和程序反应了业务事实。所以当我们需要了解一个系统的业务时，如果没有数据库表设计文档，可以想象系统维护升级如同一场灾难。
在DDD中，我们也有与之向对应的东西：实体。但在考虑和设计实体时，是不考虑其如何存储的，所以在我看来实体和库表设计很像，但又不是一回事：比如库表设计考虑关联关系，实体虽然也考虑，但这个不是特别重要，我个人认为考虑实体要考虑这个实体的归属，即设计实体一定是基于领域划分之内的，也就是说这个实体设计时，你应该考虑由哪一个限界上下文来维护其 生老病死，这才是重中之重。
那我们先来解释什么是限界上下文？
限界上下文可以通俗的讲就是你的微服务中的一个微服务。上一篇我们的确划分了领域，但领域并不等同于微服务。在一个领域内，有众多的实体对象，那么这些实体对象的出生，更新，到最后的死亡，都应该只和一个界限上下文有关。比如订单这个实体，那么创建这个订单，更新这个订单的状态，更新这个订单的信息等等操作应该都是一个限界上下文来操作（订单或交易中心）负责，界限上下文是为相应的实体对象而存在的。
在这个限界上下文中，我们拥有了实体，但实体一定有对应的变化场景：更新，状态变化，信息更新，删除等等，那么对应的这些变化一定有对应的命令来触发。只是这个命令不是一个技术名词，而是一个业务动作而已，所以命令是伴随者实体而生的。
当我们搞清楚了实体（由对应的限界上下文维护生命周期和属性更新），那么我们就可以开始通过用例分析来归类相应的界限上下文的应具有的功能接口清单，从基于前面已经有的用例分析，我们可以找到其中的有关实体和对应的命令：比如上面的对账批次，损益单，对账文件等等；相关的命令有：审核，生成，调整，录入等等。
通过以上的分析，我们大概可以形成这样的一个具备可读性（业务人员，产品人员，技术人员）文档
而且将所有限界上下文用例文档合并起来，应该是包含了该系统的所有的用例的。
这个表中的的一项“输出事件”是由技术和业务 来拟定（后续会再领出来讲），主要是通知其他上下文告知已经完成了某个动作，做为其触发的依据。此文档一定是所有的参与人员都能读懂的。
网友评论