角色目標實體建模法缺少對於流程的描述; 雖ˋ然在 stage4 的時候有提到 RD 會對業務方說明, 但是這個知識並沒有被保留在某個地方, 時間流逝或者人員異動就會消失; 想到的解決方式: 把原本的表增加一個欄位, 流程簡單的話就直接備註, 複雜的話當作文件索引, 用其他文件補充(流程圖) 只是這樣子是否會變成寫了太多實作細節, 變成在模型寫了一份偽代碼?

云带来了哪些运营模式的变化？像例子中，举动极客时间专栏提供了企业版，这个变化跟 云的关系在哪呢？请教老师细细解释下呢

刚开始学习，浅显的认识：统一语言是不是相当于现在的 “需求说明书” ？ 有什么不同点？ 1. 需求说明书应该只算产品部与技术部沟通的文件，统一语言是想要统一所有部门和甲方？ 2. 目前需求说明书模式的一般都是第一版写完，后面技术改改改，就懒得同步了，后面很多对不上的，统一语言目前说的改语言等于改模型，改模型等于改代码的思想很先进，但是是通过人力实现的吗？，还是有系统性的控制？因为90%的一二流人才都在大公司，小团队只能招到三四流人才并在一二流人才里面捡漏，要求太高则无法执行。

请问徐老师，业务架构师的主要工作是不是业务建模呢？ 业务架构和业务建模两者之间有什么本质区别呢？

重读疑惑： 先说结论： 仅看极客2c的App，聚合应该是Column，而不是Author。 论据： 1.用户查看资源的核心目标是 Column。 2.用户付费购买的核心单元是 Column。 3.用户没有购买 Author的诉求，仅是通过 Author 查看其下的 Column。 类比: Column就像电商网站的商品， 计算机基础/后端/前端/产品 这些就像是类目, 而Author就像是品牌。有些场景我需要查看某品牌下的商品，有些场景我需要查看商品是属于哪个品牌的，但我不会购买品牌， 品牌只是商品关于信誉这个维度的补充信息。作者之于专栏也是如此。 旁外话: 仅看看极客2b的App，以Author为聚合就没毛病。再次类比电商，Column依旧是商品，但Author这时候就是具体的供应商。我只会和供应商谈合作，签合同，做结算，而不是商品。

订阅专栏跟送朋友专栏这两个API，HTTP 方法和 URI是一样的，无法区分，一般来说，当前用户的身份都会通过HTTP cookie进行鉴权，所以建议订阅专栏的URI直接简化为/subscriptions，送朋友专栏的URI为/users/{friend_id}/subscriptions，这两个API都由User-Subscriptions聚合来实现

评论里有一些很牛的总结和想法，值得反复阅读品味，感觉极客时间缺少能让我们收藏的功能，或者统一查看自己点赞过的评论功能！

醍醐灌顶，领域和业务的概念分离，解决了困扰自己很久的问题。学习就是打破固有认知，重新构建知识边界的过程；从这个角度来看，这个专栏可谓大作。

URI是不是太长的问题，让我想起了代码层面违反迪米特法则的情况。它们的共同点是暴露了一个层级结构。 如果说因为URI体现的是稳定的业务模型，所以暴露层级是合理的，那么是不是在代码层面，如果对象层级符合模型，也不需要在意迪米特法则呢？

貌似开了点窍，总结一下，有把锤子哪里都是钉子，有了一套解决方案什么问题都能套得上，但不是每个问题都是同一个问题 由具体问题抽象出解决方案，再在解决方案指导下给出处理具体问题具体路径 问题N：N模式 转化为 问题N：1 解决方案 1：N具体模式 这是N:N的关系，必然从一边是推导不出另一边的 文中的每个问题抽象出是要可扩展，解决方案是面向接口编程，但每个问题都不同，所以具体行为也不同，策略模式是应对行为，状态模式是应对状态 解决方案是一个，可问题却各自具象，魔鬼在细节 能力供应商模式也是同样的，从表面看是接口定义在domain,实现在其它地方，保证domain的稳定，形式上跟很多相似，ACL、整洁架构，也就是解决方案相似，但其实解决的具体问题不同，所以不能说能力供应商就是ACL 很多时候程序员不是在编写代码，而是在摸索业务领域知识；也就是从当前的代码去推测当时在解决什么问题，再重新定义问题，进行重构，这是因为知识没有有效传承，或者没有达到代码即模型