领域建模刍议(一)：
分清问题域和问题解决域
领域与领域模型
俗话说，人人心中有一个Hamlet，人人心中也都有一个领域模型的定义。
常见的有：
说法1：我理解的领域是对业务工作进行归类划分，归类的方式是业务工作具有相关的知识，这些所需要的知识构成一个领域，这些知识是业务工作的背景，通过对领域的分析，可以帮助我们挖掘、分析、理解业务工作的本质。 也就是说，领域是为需求分析工作服务的，它的目的是挖掘、分析、理解业务工作的本质。
说法2：领域模型就是对领域内的概念类和现实世界中对象的可视化表示。
说法3：企业应用架构模式中明确提出了三种领域逻辑组织模式：事务脚本、领域模型和表模块。领域模型同时将行为和数据作为领域逻辑的核心。
从上面可以3种说法，可以看到不同上下文不同的观点，甚至未必是同一个表达对象。企业应用架构模式中的领域模型是设计到实现层的一个概念，而说法1，说法2种的领域是业务层面及分析阶段的一个概念。因此，本文特指[领域模式]为业务视角的模型，引用定义如下：
• 领域: 是相对于系统而言的，是系统要解决的现实问题。
• 领域模型是对领域内的概念类或现实世界中对象的可视化表示（百度）
• 领域模型是针对某个特定问题的所有相关方面的抽象模型(Wikipedia)
思考，如何对上图的元素建模？
领域建模的好处
领域建模的好处，有哪些呢？
不同角色统一语言、统一认知
如上图所示，客户需求历经演变之后已经面目全非，每一个加工制造环节都以为在[正确的做事]。君不见这样的生动局面一再上演：
产品经理宣讲prd，产品经理需要分别把名词翻译给业务方和开发人员，一则业务语言，一则技术语言。
几个架构师在小黑屋吵了半天，为了争论一个名词定义。比如什么是支付？百度百科的解释：社会经济活动所引起的货币债权转移的过程。包括：交易、清算、结算。
那么对于下列情况是否属于支付范畴就是可以根据其内涵来比照了。
- 用户A转账给B。
- 用户通过某某网站还信用卡。
- 用户在天猫购买了一个东西，使用花呗付款。
由此可见，显性的统一语言很重要，让干系人明白讨论的是一件事情。
对业务本质描述，抓到主旨
比如在支付宝渊源的发展过程中，我们先后使用有红包、实时优惠、商户优惠券等产品。这是烟囱式架构发展下的产物。
行业也有其它类似券的东东，如下图所示：
这3个产物我们锊一下：
1、 对于商户或者机构而言，这些是否可称之产品，可以面向商户售卖包括收费。
2、 对于用户而言，是否需要理解这3个东西不同的？这些认知对于营销，对于交易促成，对于品牌的好处是什么？
3、 对于支付宝平台而言，他们的管理模式有何区别？
4、 对于技术团队而言，他们是否可以抽象？
后来，我们在产品上形成了如下定义：
券定义：
是一种票据，作为券发行方和拥有方之间凭证，具有一定的价值和法律效应。
相关干系方：
券的发放方[提供权益]
券的拥有方[享受权益]
劵的发放工具[是券发行方向拥有方发放券凭证的工具]
券形式：
以介质分类：纸质券，电子券
以使用方式分类：入场券，礼品券，提货券，代金券、红包，打折卡，满减卡等
可以把券作为基础产品，在业务形态上可以包装为打折卡，满减卡等用户感知的[产品]或者是[营销工具]。
