一次领域建模的实战之旅

和建模相关的知识主要来自[分析模式：可复用的对象模型]，或者DDD（Domain-Driven Design）或者彩色UML建模。软件从业人员有写不少写多年代码的同志并不了解领域建模，以为是数据库物理表关系图。而2个架构师对于同一业务场景建模，往往也很难完全相同，建模本不是创造，是业务领域通过一种描述语言的自然反映，但由于描绘它的架构师有自己经验、知识、认知角度、美学等各方面的差异，导致了这多样的美丽。或有人问，什么样的模型是好的，这无疑是天问，本文通过近期的一次工作坊式的实践活动或许能提供线索...

工作坊采取分team的方式，有效投入时间7h+。1个team以3人为佳，有些team4人要形成结论更困难。

10: 00-12: 00 建模及设计（1小时 分组，1小时讲解）

12：00-13：00 午餐及自由

13：30-18：00- 展示程序，包括测试代码

18：00-19：00 show，评点等

题目内容

A公司的收费方案：所有的电话被分为白天电话和晚上电话。白天电话的时间从早晨7; 00到晚上7：00，剩下的时间算为晚上。白天的电话费用：第1分钟98美分，接下来每分钟30美分。晚上的计费方式为：第1分钟70美分，接下来20分钟收20美分，其余的每分钟12美分。政府对每人每个月的第1个50美元的电话收6%的税，其余收4%的税。

要求：1、完成该需求的领域模型

2、考虑一定的扩展性

3、使用你喜欢的语言对模型进行代码实现，并证明其符合需求预期。

要求：分team进行，如时间充分，考虑进行第二轮功能增强

第一次建模成果

重构结果分别是

代码就先不展示了:)(该题目推荐给做练习的团队，老少咸宜)

从过程可以观察到一些有趣的现象：

1、跨项目组打散分组，可以观察谁成为自然发言的中心

2、总有保持个人风格，而相对融入慢的同学，他坚持自己的意见，又可能没有搞定其他人

技术层面

1、当我们讨论领域，业务对象的时候，不要说系统名称、通讯协议、实现语言等实现层面的内容，拜托！

2、统一语言（名词），比如 订单，话单，账单，流水

以2组的产出为例，计费流水、计费明细、计费账单都是什么鬼！如果套用账务，财务域的概念，计费明细=明细账，计费账单=月汇总账单（默认按月汇总，可以提供不同汇总周期），而计费流水本身是用户拨打电话产生的通话记录

3、区分子域或层面，比如通话记录不能耦合到计费域

4、考虑变化，比如本题的核心之一在于计费规则。从从业务领域到实现域转换的时候，规则处理模块要考虑规则叠加优惠组合等情况，当下设计的实现成本。

#the end#

艺宅男的情怀

重要的事情说三遍，干货、干货、干货！