薪水支付系统领域驱动设计实践

(一)    通过领域驱动设计想解决什么问题

一个系统,按理说针对的行业是固定的,业务也比较接近,可是每次换个用户,总感觉需求变化一点点,系统却要改得天翻地覆.修改后的代码让不忍直视,心里暗暗嘀咕,神呀,千万不要再找我改了….why?

后来慢慢的接触到面向对象开发，才慢慢的理解了原因，我们以前的系统都是基于数据为中心的系统。以数据为中心的系统最大的弊端我认为是很难从中直观的理清原来的业务问题和解决思路，你要想搞清楚这些，就需要理解表结构，理解sql语句，跟踪具体的数据变化，即时这样可能还是印象模糊，你可能还需要配合ui一步步操作并跟踪数据的变化才可以理出头绪。总之，没有一个清晰的模型让你快速的理解原有的完整思路。

而面向对象,更具体的讲面型领域驱动设计方式以形成通用语言，然后基于通用语言设计领域模型，再以模型为核心，围绕模型进行开发。如果以后要了解系统，很简单，集中精力了解通用语言和模型基本上就可以了。而后续的变动，首先是对通用语言和模型的变动，然后再将模型的变动反映得代码中，这样的变动是一种有序的变动，而不是像以前跟在数据屁股后面。这样，我们才能不断的将业务收集、沉淀下来，最终反映在产品的竞争力上。

既然领域驱动设计这么好，为什么大多数公司还是采用以数据为中心的开发模式呢？究其原因：难以掌握。好像一个分界线，一旦掌握了领域驱动设计，感觉从哲学的层面升华了系统开发的思维方式，从而不再过多地受制于具体的编程语言和技术框架。

说了这么多，实际上本人也是摸着石头过河，便学边实践。只是想通过这种方法来提高学习效果。

(二)    实例描述

该系统由一个公司雇员数据库以及和雇员相关的数据（比如：工作时间卡）组成。该系统必须为每个雇员支付薪水。系统必须按照规定的方法准时地给雇员支付正确的数目的薪水。

l 有些雇员是钟点工。会按照他们雇员记录中每小时报酬字段的值对他们进行支付。他们每天提交工作时间卡，其中记录了日期以及工作小时数。如果他们每天工作超过8小时，那么超过的部分会按照正常报酬的1.5倍进行支付。每周五对他们进行支付。

l 有些雇员完全以月薪进行支付。每个月的最后一个工作日对他们进行支付。在他们的雇员记录中有个月薪字段。

l 同时，对于一些带薪雇员，会根据他们的销售情况，支付给他们一定数量的酬金（commission）。他们会提交销售凭条，其中记录了销售的日期和数量。在他们的雇员记录中有一个酬金字段。每隔一周的周五对他们进行支付。

l 雇员可以选择支付方式。可以选择把支付支票邮寄到他们指定的邮政地址；也可以把支票保存在出纳人员那里随时支取；或者要求将薪水直接转帐到指定银行卡号。