领域模型和领域对象的概念
是对领域内的概念类或现实世界中对象的可视化表⽰。⼜称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本⾝，发掘重要的业务领域概念，并建⽴业务领域概念之间的关系。
⾯向领域对象设计的原则简单的说就是起名字定职能，对象定领域，关系做关联。俗话：起名字，画圈，画线。
领域模型是为了解决问题，所谓领域就对应⼀个问题或者主题。
领域解决了再解决表述和表述持久化的问题。
先来完成最简单的部分，即关系。也就是说，按照所谓的关系，我们来重构事务脚本中的代码。上篇“”中同样的需求，如果⽤领域模式来做的话，我们⼤概可以这样设计：
概念
业务对象模型（也叫领域模型 domain model）是描述业务⽤例实现的对象模型。它是对业务⾓⾊和业务实体之间应该如何联系和协作以执⾏业务的⼀种抽象。业务对象模型从业务⾓⾊内部的观点定义了业务。该模型为产⽣预期效果确定了业务⼈员以及他们处理和使⽤的对象（“业务类和对象”）之间应该具
有的静态和动态关系。它注重业务中承担的⾓⾊及其当前职责。这些模型类的对象组合在⼀起可以执⾏所有的业务⽤例。
核⼼元素
业务⾓⾊显⽰了⼀个⼈承担的⼀系列职责。业务实体表⽰使⽤或产⽣的可交付⼯件、资源和事件。业务实现显⽰了协作的业务⾓⾊和业务实体如何执⾏某个⼯作流程。使⽤以下⼏种图来记录业务⽤例实现：图显⽰参与的业务⾓⾊和业务实体。活动图，其中泳道显⽰业务⾓⾊的职责，⽽对象流显⽰如何在中使⽤业务实体。序列图描述业务⾓⾊和业务主⾓之间交互的详细情况，并显⽰如何在业务⽤例执⾏过程中访问业务实体。
业务对象模型将结构的概念和⾏为的概念结合了起来。
它是⼀个纽带⼯件，⽤于对业务关系进⾏清晰的表述，表述⽅式与软件开发⼈员的思考⽅式类似，同时仍保留⼀些纯粹的业务内容。将我们所知道的有关业务的信息按照对象、属性和职责进⾏了合并。
它探索业务领域知识的本质，所采⽤的⽅式使我们能够从对业务问题的思考转变到对软件应⽤程序的思考上来。
它是⼀种确定需求的⽅法，使需求能够为待建信息系统使⽤，并得到该系统的⽀持。
确定业务对象定义、对象间关系、对象名称和对象间关系名称的流程使我们能够以⼀种能被业务领域专家理解和验证的精确⽅式来表达业务领域知识。
领域模型
命名
对每个业务⾓⾊和实体进⾏命名，要求名称能够表⽰对象的职责。
⼀个好的名称通常是名词或动词的名词形式，每个名称都必须是唯⼀的。避免使⽤发⾳或拼写类似的词以及同义词作为名称，可能需要⽤好⼏个单词来组成⼀个明确的、⽆需额外说明的名称。
对象
当您研究参与业务中不同的业务⾓⾊和业务实体时，可能会发现某些对象如此相似，以致于实际上是⼀个类。即使不同的业务⽤例没有相同的要求，类是之间也可能相似到⾜以被视为⼀个相同现象的程度。如果是这种情况，您应该将相似的类合并在⼀起。这就产⽣了⼀个业务⾓⾊或业务实体，它拥有⾜以满⾜不同业务⽤例要求的关系、属性和操作。
因此，多个业务⽤例可以对同⼀个类有不同的要求。对于业务⾓⾊来说，如果有些雇员有能⼒担当所
描述的⼀组⾓⾊，那么同样还要有⼀些⽐较灵活可以胜任多个职位的雇员。这会使您的业务更加灵活。
模型
在业务对象模型中，业务⾓⾊代表雇员将担当的⾓⾊，⽽业务实体则代表雇员将处理的对象。⼀⽅⾯，可以使⽤业务对象模型来确定业务雇员将如何进⾏交互，以产⽣业务主⾓所期望的结果。另⼀⽅⾯，系统⽤例模型和设计模型指定了业务的信息系统。
和系统建模解决不同的问题，其抽象程度也不⼀样。所以⼀般⽽⾔，信息系统不应该直接出现在业务模型中。
另⼀⽅⾯，雇员作为业务⾓⾊来使⽤信息系统，实现相互之间的通信、与主⾓的通信以及对业务实体信息进⾏访问。所有的链接、关联关系或属性都有某个潜在的信息系统对其进⾏⽀持。
这两类建模环境有以下关系：
作为特定业务⾓⾊的雇员与信息系统的⼀个系统主⾓相对应。如果建⽴的信息系统使该雇员在业务中的所有⼯作都得到⼀个系统⽤例的⽀持，则他最有可能得到最
好的⽀持。另外，如果业务⽤例规模⼤、⽣存期长或者合并了多个独⽴领域中的⼯作，信息系统⽤例将可以⽀持业务⾓⾊的操作。雇员⼯作的对象（建模为业务实体）常在信息系统中得到表现。在信息系统的对象模型中，这些业务实体作为出现。业务实体之间的关联关系和聚合关系常常使设计模型中实体类之间产⽣对应的关联关系和聚合关系。因此，系统⽤例访问并操作设计模型中的实体类，这些实体类代表由被⽀持业务⽤例访问的业务实体。最后，直接使⽤的业务主⾓也成为信息系统的系统主⾓。当确定对⽀持业务的信息系统的需求时，这些关系⼗分关键。
主⾓
有时候，⼀个业务的雇员与另⼀个业务的雇员使⽤其他业务的信息系统进⾏联系。从建模后业务的⾓度来看，这个信息系统就是⼀个业务主⾓。
⽰例：某个软件开发⼈员努⼒去理解他所负责的产品中出现的问题。为了了解问题是否源于他所使⽤的编程⼯具，他与供应商的万维⽹服务器联系，并仔细研究编程⼯具当前版本中已知问题的列表。通过这种⽅式，业务⾓⾊“软件开发⼈员”与业务⾓⾊“提供商的万维⽹服务器”进⾏交互。
定位
writeline方法属于类
通常的做法是不在业务对象模型中对信息系统进⾏明确建模，因为信息系统只是业务⾓⾊所使⽤的⼯
具⽽已。但当业务的信息系统被客户直接使⽤时，这种做法就不合适了。如果这个交互是业务服务的主要部分，您可能会出于商业上重要性的考虑⽽希望在业务对象模型中将其展⽰出来。电话银⾏业务就是此类信息系统的⼀个很好的例⼦。
从业务建模的观点来看，建议使⽤以下⽅法：
将信息系统看做⼀个和主⾓交互的完全⾃动化的业务⾓⾊。如果信息系统和任何其他业务⾓⾊或业务实体相关，则考虑使⽤链接或关联关系来说明这种关系。系统可能会向某个业务⾓⾊通知其进度，或者使⽤与某个业务实体相关的信息。简单地说明业务⾓⾊，同时列出代表业务对象模型中信息系统的服务。在信息系统模型中对信息系统和其环境的所有细节和特征进⾏建模。引⼊⼀个命名约定，这样可以容易地在业务⾓⾊中确定那些完全⾃动化的业务⾓⾊，例如，⼀个前缀或后缀，如“⾃动<；业务⾓⾊名称>”或“<；业务⾓⾊名称>（IT 系统）”。您甚⾄可以使⽤⼀个特殊的图标来定义构造型。
特征
总的来看，业务⾓⾊和业务实体执⾏业务中描述的所有活动，绝不多⼀点，也绝不少⼀点。业务对象模型有效、全⾯地对组织进⾏了展⽰。
设计
举⼀个简单的例⼦来说明如何进⾏领域模型设计。
假如我们要为⼀个⼩卖店设计⼀套，她为我们提供的业务描述是这样的：每天凌晨从布吉农批市场买苹果、梨、、橘⼦、⾹蕉、荔枝、核桃等等，反正哪些好卖她就买回来卖。葡萄、荔枝不能长久保留，⼀般要当天卖出去…。
针对上⾯这段业务描述，我们怎么进⾏领域模型设计？我给出以下⼏个步骤来完成领域模型设计。
总结业务描述中的名词
⾸先建⼀个名词表，把涉及到的名词列出来：
序号名词备注；
1. 布吉农批市场
2. 买东西的⼈是⼀个隐含的名词，每天凌晨从农批市场拿货
3. 苹果
4. 梨
5. 葡萄
6. 橘⼦
7. ⾹蕉
8. 荔枝
9. 核桃
10. 顾客是⼀个隐含的名词，买回来卖的对象
11. 凌晨、当天时间名词，与实体及⾓⾊⽆关
这个名词列表包括了业务的⾏为主体：⾓⾊，以及业务过程中的操作实体：模型，对我们接下来的描述、领域模型分析、需求分析很有帮助。当然这个名词列表需要经过进⼀步分析提炼，成为领域模型
确定业务实体
序号名词描述；
1. 布吉农批市场不是本业务的⼀个实体
2. 买东西的⼈是本业务的⼀个⾓⾊
3. 苹果是⼀个实体
4. 梨是⼀个实体
5. 葡萄是⼀个实体
6.橘⼦是⼀个实体
7. ⾹蕉是⼀个实体
8. 荔枝是⼀个实体
9. 核桃是⼀个实体
10. 顾客是本业务的⼀个⾓⾊
11. 凌晨、当天时间名词，与实体及⾓⾊⽆关
抽象业务模型
经过分析，我们得出的实体是苹果、梨、葡萄、橘⼦、⾹蕉、荔枝、核桃，这些是不是模型呢？应该说还不是，还要经过进⼀步分析：在我们分析的业务领域内，它们有没有共性？苹果、梨、葡萄、橘⼦、⾹蕉、荔枝属于⽔果，核桃属于⼲果，它们都是果品的⼀个具体实例。⽽在⽔果中葡萄和荔枝属于不宜保存⽔果，通过这样进⼀步的分析得出如下的领域模型：
果品领域模型
这个领域模型不但能反映当前的经营实体，同时给我们需求分析⼈员和系统功能提供了⼀定的扩展视野：将来会不会经营⾷品，短期保持⽔果采取什么利润空间来促销，长期保存的⽔果会不会因为保存成本⽽导致利润下降。
关系
认为领域模型它是⼀个分析模型，帮助系统分析⼈员、⽤户认识现实业务的⼯具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题领域相关。领域模型是需求分析⼈员与⽤户交流的有⼒⼯具，是需求分析⼈员与⽤户共同理解的概念，是彼此之间交流的语⾔。⽽数据模型是系统设计、实现的⼀部分，描述的是对⽤户需求在数据结构上的实现，仅此⽽已。当然数据模型中的概念模型设计与领域模型类似，缺乏的是实体之间更⼴泛的关系描述。
通常⼤家会考虑数据怎么存放的问题，我的理解是领域模型设计期间不⽤考虑数据的存放问题，只考虑业务描述中涉及的实体以及实体之间的关系。
实体之间的关系，很多书都讲了，⽆⾮是泛化、依赖和关联，关联⼜分了⼀般关联、聚合、组合等等，我这⾥就不列了。
总结
领域模型设计是需求分析的。它帮助⽤户及需求分析⼈员建⽴业务概念，确定⽤户业务的问题域，系统涉及的业务范围等等。
领域模型设计的步骤为：
1. 从业务描述中提取名词；
2. 从提取出来的名词中总结业务实体，区分名词中的属性、⾓⾊、实体、实例，形成问题域中操作实体的集合；
3. 从业务实体集合中抽象业务模型，建⽴问题域的概念（例如在前⾯的例⼦中，我们把容易变质的⽔果称之为“短期保持⽔果”，当然也可以是其它说法，只要能跟⽤户达成共识即可）；
4. ⽤UML提供的⽅法和图例进⾏领域模型设计、确定模型之间的关系；
今天我们通过⼀个“超市收银”业务来作为我们的⽰例（虽然这个⽰例看上去不太正常，但是它确表述我们所需要的）。我们将从业务分析到业务建模然后最后的编码来⽤“⾯向领域对象”的⽅式来做我们的项⽬。
好，我们开始吧！
⼀、业务分析
⼤家都去超市买过东西，对超市收银业务都⽐较熟悉。什么？你不熟？好吧，那我们个收银员给⼤家讲解下（领域专家）。
收银员⼩慧：哦，是这样呢。顾客排队银帐我就收银呢，我要使⽤收银机呢。收银机就能计算出要收的钱呢，我就扫⼀下呢，就OK了呢。然后就收银了呢。
听了⼩慧的讲解，我们⼼中有了业务的概念了。我们这⾥采⽤《业务关键字分析法》来出此业务流程⾥⾯的⼀些关系字：
商品
顾客
收银员
收银机
*收银
*选商品
*收银员使⽤收银机
*收银机扫商品计算⾦额
好了，列出这些“业务关键字”了，我们就可以建我们的对象模型了。
⼆、系统建模
上⾯我们分析出了⼀些“业务关键字”接下来我们分析这些业务关键字并深⼊他们的业务。
商品对象(Goods)。
属性：商品名称(GoodsName)、商品价格(GoodsPrice)。
⾏为：在这⾥商品对象是没有⾏为的，我们也可以叫它“值对象”。
顾客对象(Customer)。
属性：顾客姓名(CustomerName)、顾客选购的商品(Goodss)
⾏为：选购想买的商品(LikeBuy)、听收银员说要收多少RMB(ListenAmount)
收银员对象(Cashier)。
属性：收银员姓名(CashierName)
⾏为：收银(CashierRegister)
收银机对象(CashierRegister)。
属性：收银机编号(CashRegisterNo)
字段：总⾦额(_totalAmount)
⾏为：收银(CashRegisters)、显⽰收银总额(ShowAmount)
有⽊有！有⽊有？有⽊有很直观，这也就是⾯向对象分析的好处，因为对象就是对现实的抽象，我们现实中的事务可以很⽅便的⽤对象抽象出来。我们很容易发现，这和⽤表来描述这些业务模型显然要不⽅便的多。表还只能描述属性，造成了属性与⾏为的分离。
三、代码⽰例
商品对象
///<summary>
///商品
///</summary>
public class  Goods
{
///<summary>
///对象标识
///</summary>
public  Guid OKey {  get ;  set ; }
///<summary>
///商品名称
///</summary>
public string  GoodsName {  get ;  set ; }
///<summary>
///商品价格
///</summary>
public decimal  GoodsPrice {  get ;  set ; }    }
顾客对象

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。