活动场景的参与者身份

1)先分清一下角色的概念吧：我在本文中的角色的含义和你所说的角色（权限的集合）应该是两个概念，你的是传统意义上的User-Role-Permission中的Role，而我所说的角色则是指活动场景的参与者身份，可以理解为拍电视剧时电视剧里的人物的角色；不仅仅是人可以扮演角色，事物、地点也可以扮演；这点我在文中已经分析过了；

2）关于角色及其扮演者的分析与结论，我也感觉有点难达成共识，看一下我发的前一篇文章就知道了。在分析阶段：我会从活动出发，分析活动参与者，即角色，然后再思考角色扮演者，从而完成整个分析；而在设计编码阶段：则从建模开始，先设计领域对象即角色扮演者，再设计角色，再编写角色交互的场景相关的代码；这是两个相反的过程；我个人认为我们在分析业务时，或者说用户在谈业务需求时，总是围绕活动或过程展开，他不会说这个聚合怎么样，这个实体该有哪些属性或行为；我个人认为Eric Evans的那套DDD模型还是很难与用户沟通，虽然程序员相对容易理解。但很多时候程序员也会产生很多理解不一致，比如聚合根的问题上，往往理解差别很大；我觉得我们在分析事物时引入角色的概念，是为了和用户大脑的思考拉近距离，实际上用户头脑中产生也都是角色，比如一个人被谋杀了，人们想到的肯定是被害人、凶手等概念，而这些概念不正是角色吗？被害人和凶手都由人扮演，如果我们把被害人的属性和凶手的属性和行为全部放在人这个实体上，显然不太合理，会导致人的职责过于庞大，虽然不违背分析原理，但违背设计原理。

3）关于你提到的DCI本质上没有解决职责如何分配的问题，确实没有！就像你所说，它只是把对象的一些依赖场景的属性和行为分散到了角色中而已；这样做也许对最终效果来说没有区别，你把所有属性和行为都放在一个对象中也可以；我认为DCI的真正好处是让我们的代码看起来和用户的想法更接近，用户说了什么交互场景，什么活动，我们的代码中也就会有什么场景，会有相应的场景参与者角色，这样做极大地提高了代码的可读性；我认为这才是DCI的真正意义所在；而这也是为什么我文中说DDD中的领域对象是静态的，只注重静态结构的原因；

4）你可能会角色这样可能会导致角色漫天飞，有点过度设计。确实，所以有时我们在真正实现的时候，可以考虑让领域对象本身就实现某些角色，这样就不用新定义角色类，但同时也不破坏DCI的理念；在我的示例源码中的图书馆这个实体类就是本色出演图书馆角色；

5）关于你提到的用贫血模型+面向过程+分层架构的开发方法，确实很容易入手，在一定程度上也很容易维护；但它同时也放弃了面向对象的理念，因为此时的对象本质上和结构体（存放数据的容器）没有本质区别；这已经不能算是真正的面向对象开发；另外，我理解的Eric Evans的DDD中的领域模型是充血的；