本文主要是介绍关于领域建模时考虑用户需求的出发点的理解，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
摘自http://www.jdon.com/42751
最近又重温了领域驱动设计的原著，有了一些新的理解。现在我觉得我能更好地理解jdon007之前说的下面这段话了。
“用 户需求”不能等同于“用户”，捕捉“用户心中的模型”也不能等同于“以用户为核心设计领域模型”。 《老子》书中有个观点：有之以为利，无之以为用。在这里，有之利，即建立领域模型；无之用，即包容用户需求。举些例子，一个杯子要装满一杯水，我们在制作 杯子时，制作的是空杯子，即要把水倒出来，之后才能装下水；再比如，一座房子要住人，我们在建造房子时，建造的房子是空的，唯有空的才能容纳人的居住。因 此，建立领域模型时也要将用户置于模型之外，这样才能包容用户的需求。
所以，我的理解是：我们设计领域模型时不能以用户为中心为出发点去思考问题，不能老是想着用户会对系统做什么；而应该从一个客观的角度，根据用户需求挖掘出领域内的相关事物，思考这些事物的本质关联及其变化规律为出发点去思考问题。
下面以Eric Evans（DDD之父）在他的书中的一个货物运输系统为例子简单说明一下。
在经过一些用户需求讨论之后，在用户需求相对明朗之后，Eric这样描述领域模型：
1. 一个Cargo（货物）涉及多个Customer（客户，如托运人、收货人、付款人），每个Customer承担不同的角色；
2. Cargo的运送目标已指定，即Cargo有一个运送目标；
3. 由一系列满足Specification（规格）的Carrier Movement（运输动作）来完成运输目标；
从 上面的描述我们可以看出，他完全没有从用户的角度去描述领域模型，而是以领域内的相关事物为出发点，考虑这些事物的本质关联及其变化规律的。比如第1点， 如果是以用户为中心的话，就变成了：一个托运人可以托运货物，即具有托运货物的行为，一个收货人可以收货物，一个付款人需要付款；而他的描述中完全以货物 为中心，把客户看成是货物在某个场景中可能会涉及到的关联“事物”，如货物会涉及多个客户，货物有一个确定的目标，货物会经过一系列列的运输动作到达目的 地；其实，我觉得以用户为中心来思考领域模型的思维只是停留在需求的表面，而没有挖掘出真正的需求的本质；我们在做领域建模时需要努力挖掘用户需求的本 质，这样才能真正实现用户需求；
这让我想到了我之前思考图书借阅系统时的出发点也是错误的，因为我之前总是在以用户为中心思考问题。比如借书者借书，借书者还书，管理员对书本入库，等等；经过上面的分析后，我觉得我应该以书本为核心出发点思考领域模型。如：
1. 一本书在某个时刻最多只能被一个人借，或者没有被借走留在图书馆；
2. 书本在被归还时需要检查归还时间，如果有超期则需要做罚款处理；
3. 一本书有库存信息，如书本存放位置，库存数量；
4. ……
没有从用户的角度去描述领域模型，而是以领域内的相关事物为出发点。
看来认识识分析需求有两种线索，一个是以人为核心的需求分析；还有一个与人无关，事物领域自身的内在规律，或者称为“道”。
至于以哪个为主要为侧重点，还是要看人和事物在不同场景中扮演戏份的多少与否，比如在货运系统中，从这个名字我们也可以看出以货为主的一个运输系统，因此，人应该处于次要地位。
但是图书馆借书这个案例中，我个人认为好像不是以书为主的自主运动，而是以人为主，书为辅助的这样一个系统，如果以书为主，就发生“书被借”这样奇幻事情发生，呵呵。
人 != 用户
比如，人口档案管理系统，系统中应有记录人的信息或者说存在关于人的模型，但这个人的模型并不表示用户。
图书馆管理系统，用户群若是“读者”，那么应该将“读者”（用户）至于模型之外；如果用户群是图书馆管理员，那么“读者”（不再是用户，哪怕命名为用户），可以置于模型之内（比如要挖掘用户兴趣模型，发现什么的人群喜欢阅读什么样的书）。
物流系统，如果用户群是“顾客”，那么应该将“顾客”至于模型之外；如果用户群是“管理者”，那么可以将“顾客”（此时已不是系统的用户）放在模型之内。
将“用户”至于“模型”之外，用户群单一时，比较容易做到；若存在多种性质截然不同的用户群时，要注意到不同用户群将有不同的心智模型，尽管它们之间可能有交集。
但是，即便将不同性质的用户群的心智模型聚集在一起，也应遵循这个原则，并需要清醒地意识到视角潜在的变化（这可能被忽略或遗忘, 从而引起混淆）。
从整体上而言，“书”、“账号”、“书库”是模型（包括其结构/状态与功能/行为上的特征），可理解为系统的结构组成；“借阅规则”是场景规约或业务规则，可理解为系统的运作规则。
用户（读者）的心智模型不仅仅包含书，还应包含账号（图书卡）、书库（图书馆）等，模型有状态有行为，但其在参与场景进行交互时的受到场景规约的约束。
一种可以尝试的思路，是从业务规则（感知场景，从中提炼出的场景规约）中发现模型，并将业务规则与模型进行整体上的分离，让模型更自由，从而可能复用于不同的业务规则，或适应业务规则的变化。
至于模型的组织可以借鉴四色 原型的PPT , 如图书馆的例子：Place(Library)、Party(Account)、Thing(Book), 或借鉴OO 的message-based的思路，将模型分类为object+message或event+handler/dispatcher; 当然，还有别的分类或组织模型的方法。
模型的使用者不应该被包含在模型内部。 ...
当你确定书是核心领域模型了，那么模型的使用者是不应该包含进来进行分析，通过借书这样一个事件 或场景的发生，模型的使用者与模型发生了关系，这时模型书还是需要一个使用者的记录的。
模型：
Class Book{
String id;
String name;
}
用户操作借书事件 激活借书服务，从而发生借书场景：
Class BookContext{
boolean borrow(Book book);
}
当borrow(Book book)事件被调用以后，拉了一泡屎，留下状态，这个书被借了，借阅者是某个用户，在数据表中我们可能有这样的记录：
book{
String id;
String borrowedUserId;
}
至于，这个borrowedUserId字段是否应该出现在Book模型中，则是另外一种设计考虑，比如我们认为borrowedUserId字段应该属于Book的状态，那么出现在BookState中比较合适，那么Book类有了一个新引用BookState:
Class Book{
String id;
String name;
BookState bookState;
}
Class BookState{
Book book;
User borrowedUser;
Date returnDate;//归还日期等
}
完毕。
我把整个过程列出来，是为了理清我们的思绪，不要让模型的状态去影响我们的分析。
以上这个分析的唯一前提是：假设这个系统是以书为核心，跟踪围绕书发生的各种事件 。
所以，我们在描述时不能以“书被借”这样去描述需求，会产生误导，因为“借书”是一个事件 ，而“书被借”是一个状态，状态是事件 的结果，事件是状态的因，而模型是事件 的核心，没有模型，事件就无法发生，就象没有电话，就没有电话铃这个事件 ，没有书，就不会有借书这样的事件 。
由以上倒退，我们知道，分析一个需求，核心模型是第一步，这一步是不应该考虑用户，前提是如果这个用户是在事件 发生时介入的话；但是如果这个用户不是事件 介入发生，而是属于模型一部分，如书的作者，那么就应该考虑用户。
我的观点是：天地不仁，以万物为刍狗。
千万不要以为是人就扔掉：驱动者和参与者的区别。在领域当中的“人”，与“刍狗”等同，没有特殊地位。在整个领域世界中，应该全是逻辑描述，即使是人，也应该以简单对象来理解，构成事实离不开万事万物。
试想一个互动功能，交朋友，没有任何独立于人的实物，把人扔掉会是什么样的效果呢？
理解驱动者与参与者区别，就可以走出误区，account很容易让人想到使用者，分开Passport和Reader不就行了？Reader是人吗？是，但他完全和Book的地位一样，“刍狗”一只而已。
“以用户为中心”的思想主要来自于登录系统——认为系统事件 参 与者就是现实世界中的用户。虽然这样的观点在一定程度上可行，但这种关联只是一个潜在的认为而已——经过登录后，认为某个现实用户（或者电脑，或者仪器， 或者IP）所发出的所有命令是系统中与这个登录所绑定的“人”发出的。这种关联是通过登录后获得，也就是说，若果没有登录，这两者应该是分离的，是两个独 立的个体。
这篇关于关于领域建模时考虑用户需求的出发点的理解的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
