指教我的加盟商户卡支付清算平台DDD模型!
业务场景描述如下:
客户使用支付卡可以支付其在特约商户那里获取服务所产生的费用.
商户需要和支付服务供应商签订一定的服务条款,并提供一定量自己的信息才能开通支付卡支付服务. 签约商户需要支付一定的手续费用给
支付服务供应商,并和支付服务供应商进行定期结算,获取自己的销售资金. 签约商户可以为客户退款.
支付服务供应商接受并处理签约商户的申请, 支付服务供应商管理签约商户的信息.
并从签约商户产生的交易中抽取一定比例的手续费,为签约商户提供定期结算,退款业务功能.
业务模型如下图:
[该贴被admin于2009-04-02 09:04修改过]
[该贴被admin于2009-04-02 09:18修改过]
业务模型
model
业务用例图如下
业务建模图如下
结合模型将业务流程在模型中走一遍:
Accountant(结算会计)登录结算平台后首先创建一个Organization(签约商户),
然后为这个个Organization(签约商户),创建并添加一个或者多个Merchant(加盟商户),
可以为每个Merchant(加盟商户)添加一个或者多个Pos(Pos终端机)
以上建立了物理结构,然后系统运转生成交易记录
举个例子:
Organization(某服装销售集团),下辖1,2,3,4,5,6个Merchant(商户)
1,2,3商户合在一块结算帐务,使用(Agreement)合同A
4,5,6商户合在一块结算帐务,使用(Agreement)合同B
这个时候需要创建2个ClearingAgency(清算代理)甲,
ClearingAgency(清算代理)乙,.
指派ClearingAgency(清算代理)甲根据(Agreement)合同A
管理1,2,3商户的结算帐务
指派ClearingAgency(清算代理)乙根据(Agreement)合同B
管理4,5,6商户的结算帐务
每个ClearingAgency(清算代理)生成一个FinalStatement(结算单),
每个FinalStatement(结算单)中包含对应每个Merchant(商户)的结算条目
Merchant Pos Organization ClearingAgency FinalStatement FinalStatementItem TradeRecord Shop都是实体
名称结尾带State的是用来存放值对象的
目前来看,业务流程在模型中可以走通.由于经验不足,还请各位大哥多多指教!
我的问题:
1:是不是每一个实体都要有对应的值对象?
2:对于这个模型,我在做模块的划分的时候根据业务功能一致,高内聚的原则是这样来分的:
图中Merchant, Pos, Organization, TradeRecord归为一个模块,因为他们反映了一个物理结构,
Organization为整个聚合的聚合根,但是实质上业务的重点是在Merchant上,所以我认为Merchant为聚合根.
ClearingAgency, FinalStatement, FinalStatementItem合在一块为一个模块,主要功能就是完成结算任务. FinalStatement为整个聚合的聚合根.
不知道这样划分是否合理,请多指教!
3:谈一下在做业务分析的时候,总是将banq大哥简化的DDD分析模型与”四色原型”中的概念相混淆,分别在做分析和设计的时候我该用DDD分析模型还是”四色原型”?我感觉他们之间有一些相似的地方,但是有不大相似,没有弄明白,请多指教!
由于小弟经验不足,但是却是非常渴望把DDD的思想应用到我的项目开发中去,真诚的请各位大哥不吝赐教!
建议使用四色模型来分析你的需求，这样能够帮助你更全面掌握需求全貌，DDD为领域驱动设计，更侧重设计，尤其初学者掌握DDD设计有限情况下，要借助更多方法帮助自己分析需求，建立模型。
例如你画的那个类图，一下子就有十几个类，对于我们这些外行来说，不容易看清楚你的设计思路，如果你给这些类图标上颜色，那么我能根据四色一下子了解你业务重点是什么，也可以帮助审核一下，四色归类是否正确，虽然你写了很多文字表达需求，但是文字一多，就不容易让人一下子看出业务重点，主要和次要的文字都挤在一起。这些都没有四色这个象来的直观，而且大家有讨论的基础和标准，否则，你说你创建这个类有你的依据，我有我的依据，无法统一，那么通过四色图来统一沟通，就沟通容易多。
[该贴被banq于2009-04-02 09:14修改过]
非常感谢BANQ大哥的指教,我会根据你上面的指导画出四色图!
