领域建模刍议(一)： 

分清问题域和问题解决域

领域与领域模型

俗话说，人人心中有一个Hamlet，人人心中也都有一个领域模型的定义。

常见的有：

说法1：我理解的领域是对业务工作进行归类划分，归类的方式是业务工作具有相关的知识，这些所需要的知识构成一个领域，这些知识是业务工作的背景，通过对领域的分析，可以帮助我们挖掘、分析、理解业务工作的本质。 也就是说，领域是为需求分析工作服务的，它的目的是挖掘、分析、理解业务工作的本质。

说法2：领域模型就是对领域内的概念类和现实世界中对象的可视化表示。

说法3：企业应用架构模式中明确提出了三种领域逻辑组织模式：事务脚本、领域模型和表模块。领域模型同时将行为和数据作为领域逻辑的核心。

从上面可以3种说法，可以看到不同上下文不同的观点，甚至未必是同一个表达对象。企业应用架构模式中的领域模型是设计到实现层的一个概念，而说法1，说法2种的领域是业务层面及分析阶段的一个概念。因此，本文特指[领域模式]为业务视角的模型，引用定义如下：

•     领域: 是相对于系统而言的，是系统要解决的现实问题。

•       领域模型是对领域内的概念类或现实世界中对象的可视化表示（百度）

•     领域模型是针对某个特定问题的所有相关方面的抽象模型(Wikipedia)

思考，如何对上图的元素建模？

 

领域建模的好处

领域建模的好处，有哪些呢？

不同角色统一语言、统一认知

如上图所示，客户需求历经演变之后已经面目全非，每一个加工制造环节都以为在[正确的做事]。君不见这样的生动局面一再上演：

产品经理宣讲prd，产品经理需要分别把名词翻译给业务方和开发人员，一则业务语言，一则技术语言。

几个架构师在小黑屋吵了半天，为了争论一个名词定义。比如什么是支付？百度百科的解释：社会经济活动所引起的货币债权转移的过程。包括：交易、清算、结算。

那么对于下列情况是否属于支付范畴就是可以根据其内涵来比照了。

• 用户A转账给B。
  
• 用户通过某某网站还信用卡。
  
• 用户在天猫购买了一个东西，使用花呗付款。
  

由此可见，显性的统一语言很重要，让干系人明白讨论的是一件事情。

对业务本质描述，抓到主旨

比如在支付宝渊源的发展过程中，我们先后使用有红包、实时优惠、商户优惠券等产品。这是烟囱式架构发展下的产物。

行业也有其它类似券的东东，如下图所示：

这3个产物我们锊一下：

1、     对于商户或者机构而言，这些是否可称之产品，可以面向商户售卖包括收费。

2、     对于用户而言，是否需要理解这3个东西不同的？这些认知对于营销，对于交易促成，对于品牌的好处是什么？

3、     对于支付宝平台而言，他们的管理模式有何区别？

4、     对于技术团队而言，他们是否可以抽象？

后来，我们在产品上形成了如下定义：

 

券定义：

是一种票据，作为券发行方和拥有方之间凭证，具有一定的价值和法律效应。

相关干系方：

券的发放方[提供权益]

券的拥有方[享受权益]

劵的发放工具[是券发行方向拥有方发放券凭证的工具]

券形式：

以介质分类：纸质券，电子券

以使用方式分类：入场券，礼品券，提货券，代金券、红包，打折卡，满减卡等

可以把券作为基础产品，在业务形态上可以包装为打折卡，满减卡等用户感知的[产品]或者是[营销工具]。