催化剂方法和角色 - 目标 - 实体法，只得到了静态模型，没有业务流程。比如专栏可以通过”订阅“得到，那”订阅“的业务流程是什么样的模型里面没提到。基于以上，我的改进是为每个交互添加流程描述

课后题 角色 - 目标 - 实体法，和产品经理整理的用户故事及其相似。其缺点也很明显，缺少业务流转和完整性的显式化表达。可借鉴产品经理使用的用户故事地图，通过关键事件流进行建模。而对于简单的业务，特别是单体架构，使用Eric DDD中的Serivce进行封装建模。

催化剂法有点像将用例向后展开出模型的意味，角色目标实体法可操作更强，通过表格的形式梳理业务流程和关联的实体。不过，实际业务中有很多异步业务流程，如何在模型中描述这些异步流程呢？

业务在领域模型中的展开，不可以借助时序图吗？

既然想用领域模型作为统一语言这么麻烦，为什么不直接构造额外的统一语言，用领域模型作为统一语言有什么优势吗？

我发现很多方法/模式其实都是同一件事情的不同侧面和表述方式。 比如我认为文章中提到的【催化剂法】【角色目标实体法】，在软件实现阶段的一种具体实现方式是【行为驱动开发】。这些东西只是在不同的时代、时间点、场景下，有一些修正性的不同。整体的指导思维是基本一致的。 我使用BDD时间比较长，所以根据我的经验：纯粹【催化剂/角色目标实体法】能很好的解释单个操作/目标将会发生的事情，但是知识会非常的碎片化。如果不加以整理和讨论，用户将无法对整体业务流程有一个很好的理解。 感谢老师帮我梳理知识，继续认真学习！

角色-目标-实体的不足：本质上是一颗树，因此对于位于“叶子节点”的实体，缺乏了“对象间关系”这一层信息。而催化剂方法的对象关系描述的很清楚，是一张网。缺乏的是“交互”没有“软件组件”的对应。 除非，我们最终的模型产物=表格+对象关系图，否则这两种方法都只看到不同的侧面，都有缺失。

催化剂法最左边的用户，和模型语言中的用户概念上应该是一个。但左边更像是用例图，会有一点混乱的感觉。角色目标实体法则感觉太独立，缺乏一个比较直观的全局视角。

角色目标实体方法要结合domain storytelling使用更好