一直想系统的整理一下自己有关Domain Model实践的尝试。但总觉得自己的想法还不够系统而作罢。
然而从另一方面看“系统的东西”也许永远做不到，失去了目标的生活该会多乏味。
因此我决定将自己有关Domain Model设计的有关实践和思考和盘托出，也算是抛砖引玉。欢迎大家
参与讨论，遇到同你的观点相左的地方，希望能以包容的态度来面对，我们是朝同一方向走的伙伴而不是
相互对视的敌人。：）

在深入讨论之前我先抛出一些原则和概念，最后你会看到这些概念和原则的威力。
1.按照概念依赖的原则来组织业务层。
2.将业务活动（业务流程）建模成类。
3.用业务活动（业务流程）作为关联整个业务层各种对象的骨架。
4.在业务活动中凿出扩展点，使用不同接口分离不同性质业务对象。
5.将对象的存储理解为业务层概念。
......

概念依赖

这是我认为能否得到良好业务层最重要的概念。
在我系统框架设计将要完成，开始涉及业务层设计时，我脑袋一片空白，书上，大家讨论的大多是整个系统的结构从UI层
到服务层到数据访问层到数据库。到底业务层该如何组织？Martin Fowler的POEAA的书中没有回答。找到的相关
书籍也都过于空泛。Martin Fowler的分析模式有些用处，但不够系统。透过Martin fowler网站，我拿到了
Domain Driven Design的发行前版本。该书给了我很大的启示。其中的要点有：
关于关联：
1.Imposing a traversal direction (强制一个关联的导航方向)
......
关于Responsibility Layers（业务职责层）的划分：
作者给出了三个指导原则：Conceptual dependency.(概念依赖)为其中一项。
书中给出的描述的是业务职责层上层的对象需要通过下层对象才能在概念上完整，
相反下层对象则可独立于上层对象存在含义。这样天然的下层对象相对于上层对象
会更稳定。并且在今后演变的过程中，使同扩展的方式来完善系统，而不是改变对象
的方式。
通过实践，我觉得这条原则可以应用在任何两个有关联的业务对象上。通常可以通过
概念依赖先建立一个导航方向。这能够满足大多数的需求。当确实需要反向导航时，
只要理由充分可以随时加上，并且如果先前将这两个对象放入不同包中，这时需要
将他们合并到同一个包中。
我见过一个不好的设计。Customer具有很多Flag分别标记该客户是否挂失，冻结，注销等等。
通常叫做客户状态,然而这是不对的，这违背了单一职责原则。事实上除了注销外
挂失和冻结都不应该算作Customer的本质属性。相反我把他们看作某种约束，进而把挂失看作
一种协议.....因为Customer的概念可以不依赖于挂失和冻结的概念，相反挂失和冻结却要依赖
Customer的概念，应为这是他们动作的主体。
同样的一开始就让Customer有GetAccount的方法同样不好。因为Customer的概念确实不依赖Account
XXXAccount却可以有Customer的属性，Account在概念上依赖Customer。

安徽新华电脑学校专业职业规划师为你提供更多帮助【在线咨询】