设计领域模型有哪些难点？有哪些指导原则？

一、设计领域模型的难点：
1.如何提取概念类：
获取领域模型所需素材通常有两个途径：与客户现场交流中获得，和在用例的各个流程中提取名词或名称短语获得，这些我们称之为概念类。
现在的问题是，哪些应当成为领域模型中的概念类呢？如果我引用一堆定义和准则，并不能让你清楚明了，也许一个生动的比喻更能够让你理解深刻。
需求分析有时候就像一部部动画剧，而那些枯燥乏味的概念，纷繁复杂的流程，在这些动画剧中似乎都突然活了，个个都有语言有性格。
在这些动画剧中扮演的所有角色，就是我们需要的概念类。而他们做的所有动作，就是用例模型中的所有流程。
另一个比较挠头的问题就是，业务领域中的哪些概念应当成为概念类，哪些应对成为概念类中的属性。
这是一个非常模糊的问题，没有一个准确的答案。一般来说，如果一个概念记录的仅仅是一段文字或一个数字，那么它应当作为一个概念类中的某个属性，否则就应当作为一个概念类。
比如“快递员送快递”，这里的“快递员”、“快递”都是从中提取的概念类，但是“快递”中的“地址”呢？这要看你现在分析的这个系统如何去记录这个“地址”了。
如果记录的仅仅是一个文本，那么它应当成为“快递”中的一个“地址”属性；如果记录的不仅仅是一个文本，而是精细地记录了“邮政编码”、“城市”、“街道”、“通讯地址”等信息，那么它应当成为一个概念类，与“快递”进行关联。
除了这些名称和名称短语形成的概念类，还有一些相对独立的行为，作为服务也应当形成概念类。这一类概念类我们可以在需求分析不断深化的过程中，在以后的迭代中加入到领域模型。

2.如何对非真实世界的概念建模

3.如何避免领域模型中的概念类出现二义性。比如在与客户讨论需求的过程中，我们和客户都使用了一个业务术语，但我们对这个业务术语的理解存在着差异，以致我们花了大量时间来讨论一个问题，
却谁也没有向对方说明白自己的意思，直到最后我们发现对这个术语理解的偏差。

4.如何根据用户需求挖掘出领域内的相关事物，思考这些事物的本质关联及其变化规律？

5.对象之间的关联该如何设计？如何让关联尽量少？如何挖掘是否存在关联的限制条件？如何简化关联？

6.如何创建领域实体或值对象，是通过工厂还是直接通过构造函数？

7.如何重构模型？寻找模型中觉得有些疑问或者是蹩脚的地方，考虑对象应该通过关联导航得到还是应该从仓储获取？聚合设计的是否正确？模型的性能怎样？如何不断地完善和细化？

二、设计领域模型指导原则：
1.敏捷建模Agile Modeling – 类图的草图
（1）是否利用工具建模  创建领域模型的目的是快速地理解关键的概念，并在涉众之间交流。
（2）完美不是目标
（3）是否利用工具，酌情考虑，前期可以使用草图,后期要用工具建模,因为方便交流。
2.报告性的、或者总结性的对象，是否定义为概念
（1）视情况而定如单据若这是作为其他信息的集合则不作为概念，若单据有特殊角色如作为退货单据的凭证,则视为概念。
3. 构建领域模型，类似地图制作
（1） 使用现有的名词
（2） 剔除掉无关的、或者超出范围的一些特征
（3） 不需要额外增加没必要的概念！
4. 如何对非真实世界的概念建模
（1）有些软件系统着眼于解决领域问题，但是在现实中或者业务中很少有概念与之对应
 例如，电信领域“交换机”相关的概念
 消息、连接、端口、对话、路由、协议
5.经常容易出错的选择：Attributes vs. Classes ，原则：
（1） 如果认为某概念类X不是现实世界中的数字或文本，那么X可能是概念类而不是属性 
（2） 如果符合下列条件，可能是一个类 ：
            有很多元素构成
            有一些操作、行为
            有数量单位
6.对一些描述‘Description’性质的概念建模指导原则：
（1）定义成“描述”类的原则 ：
            如果描述内容独立于对应 的事物 ，如产品、产品 描述
            如果删除对象的同时删除 了描述，而该描述还需要 继续维护
            为了减少重复或者更清晰