简单问题？

》这样系统不是增加了系统的复杂度？还有没有其他方法？
动态代理或AOP

那第一个问题呢？领域建模的时候，用户或者是角色应该不应该和栏目类关联？

是否可以考虑一下通过Filter来管理权限呢?我的想法是限制每个用户访问的路径,比如只有管理员可以访问/yourproject/admin/XXX.do这样的路径,别人访问不了

我要问的不是怎么样实现权限(是用FILTER类实现还是用AOP模式来实现),我是想知道领域建模的时候,角色类是怎么关联的。或者在,第一次:概念模型的时候并不考虑角色类.在进行设计的时候才考虑它,也就是把，领域建模和模型的时候分开,并且领域建模的时候并不考虑全部的因素,只大概的描述项目的需求?

领域建模只是业务建模，当然有时权限会涉及一些业务，但这些都不是我们重点（除非权限系统是业务重点），不管权限是否是业务重点，在具体实现时，权限可以和总是和业务系统达到最大程度的分离，这些我已经在JiveJdon3完全实现，从业务层分离 到表现层。

>角色类是怎么关联的
另外，角色类关系比较好设计，基本是继承或无关联的关系。

角色权限和业务模型结合是一个体系问题，涉及系统的各个层：表现层和业务层等。在JiveJdon3中，我目前设计考虑了下面几点：

ACL一般考虑下面情况：方法操作是否有权限访问？资源数据是否有权限访问？数据资源或操作是否允许被显示？详细描述如下：
1. Web资源，主要是以Web URL为特征，对Web资源的Jsp/Servlet 图片等目录下全部资源实现授权访问。
2. 组件资源，同一个组件的不同方法实现对资源进行不同性质的操作，每种操作方法都需要实现授权访问，例如：A角色可以实现帖子创建，但不能实现帖子删除。
3. 模型资源，业务模型只能让特定角色一些访问。比如某个帖子模型只能让积分超过多少的用户访问。其中必须解决与该模型关联的子模型访问权限关系，如帖子的上传图片也必须进行授权访问。
4. 是否需要显示，如果当前用户无权修改帖子，就无需在显示帖子是，输出“修改”链接字样。
解决方案：
1. Web URL资源授权访问，采取基于容器的安全体系，配置web.xml
2. 组件方法授权访问。 采取AOP拦截器方式实现，见PermissionInterceptor
3. 模型资源访问。 采取显式代码实现，见ForumMessageShell
考察整个授权系统，对象生命周期看两种：
1. 全局Application级别的授权规则，如上面Web.xml配置，就是属于全局性质，这类可以用配置实现，组件方法访问授权也属于这一种，使用OperationAuthorization来表达，详细在下一章讨论。
2. 动态Session级别的授权，这类授权需要根据用户动态登录后，根据登录后该用户的角色，再配以动态规则，决定某些资源是否能被操作，例如帖子只有被帖子作者或管理员可以修改。使用ResourceAuthorization表达。

JiveJdon3试运行网址：
http://www.jdon.com/jivejdon/

谢谢BANQ的解释,我总是以"新闻发布系统"为例子,目的是想让其他初学者象我一样,能够了解到一个项目的全部过程,从需求分析到,编码,测试.

领域建模,根据我现在的了解,在第一步:概念模型的时候,它是不受程序设计语言影响的，从宏观的角度描述一个系统的需求.

然后接下来可能就是设计建模,根据领域建模以及UML,考虑所使用的开发语言进行建模型

接着是开发,测试

我想,关于权限的处理,更多的时候可能是放在"设计建模"这个阶段吧?

从分析和设计阶段都涉及权限，Evans DDD将分析和设计阶段合并在一起，所以可以说，以后没有分析和设计这两个阶段之分，历史证明：这两个阶段的人为分离造成了很多牛头不对马嘴的软件系统。

现在只有一个阶段：建模。建模将分析和设计统一在一起。

当然，在建模之前有需求，需求我主张使用Use Case，用例来搜集和表达，在用例中，首先明确的就是角色，什么角色做什么事情，所以权限其实从需求一开始就要确定，这个系统给谁用？哪些功能给哪些人用？

在需求后面有一个四色图分析模式，四色图中有一个最重要的就是角色，如果我们把用例需求比喻成一张巨大地图，那么四色图可以说是一个便于观察的放大镜，放大镜能够帮助我们认识和看清楚需求（地图），进而形成我们自己脑海中的隐约模型。

下面，就是使用Evans DDD进行模型轮廓确定以及关联确立，完全进入DDD的模型对象反复确立的迭代过程了。

领域模型确立后，基本可以考虑实现平台：.NET或j2EE，如果是J2EE，还必须考虑J2EE架构选择，Java世界有很多框架，现在是一个框架为王的时代，所以选择好的适合的框架，这些都是领域模型生存运行的土壤。所以，必须搞清楚，我们的平台架构选择是为了领域模型更好生存。

打个比喻，领域模型好像是你从外面买回来的金鱼（当然实际是我们脑海中抽象对象），那么你必须选择适合鱼缸和水，淡水鱼不能放在海水里养，鱼缸和水的选择实际就是平台架构的选择，有时，我们常常在平台架构选择中迷失方向，被各种花言巧语新名词迷惑，没有自己主见，关键实际没有自己的领域建模概念。

只有了自己的领域建模，才能根据自己的模型选择其生存的架构平台，鞋子大小只有自己知道，当然并不是说，拒绝先进，保守，DDD本身是2004年才出来，是新技术，可以说，完全符合DDD要求的框架还没有（包括Ruby on rails），只要符合DDD精神基本可以。

一般我都是先写好用例,然后在进行领域建模,然后就遇到了在领域模型中角色类不好表示的现象,而且领域建模中没有方法只有属性好象?

如果领域模型完后,再结合四色模型，或者,四色模型是在领域模型的基础上得来.那好象更容易理解些,请问是不是这样一回事?谢谢

我认为光有属性的领域模型并不能诠释整个系统的需求,必定需要一样东西来辅助它.而四色模型从某中角度上来说,是能够诠释系统的.(有属性,有角色,有描述以及业务).

我知道四色模型图,但是不知道怎么使用它.它是领域建模的最后结果，还是领域模型的补充?(也就是说系统需要领域模型表和四色模型表)我怎么感觉四色模型本身就属于领域模型,那以前那种光有属性的模型又是怎么回事