领域驱动设计(上):如何设计统一的金融业务模型?
目录
领域驱动设计侧重点
- 空间: 整个行业或领域
- 时间: 软件生存发展、消亡整个周期
- 角色: 是业务、产品、开发和运维等所有参与人员的合作。
领域驱动模型从宏观上解决问题,主要着手于两个方面:1. 投资回报比, 2. 做长期投资
注重投资回报比
适合领域驱动设计的系统需要有如下特点:
- 系统组件足够多
- 业务逻辑足够复杂
- 软件生命周期长
金融行业恰好都满足如上要求
软件生命周期长
人员组织架构
软件开发流程是一个内容翻译的过程,沟通的流程越长,信息损失越大。 领域模型提出的方案是,减少层级,只使用一个层级进行沟通。每次沟通,所有人员都需要参加。
常见方式:
graph LR; A(业务方) --> B(产品经理) B --> C(架构师) C --> D(开发人员)graph LR; A(业务方) --> B(产品经理) B --> C(架构师) C --> D(开发人员)
推荐方式:
graph LR; A(业务方) <--> B(产品经理) A <--> C B <--> D A <--> D C <--> D(架构师) B <--> C(开发人员)graph LR; A(业务方) <--> B(产品经理) A <--> C B <--> D A <--> D C <--> D(架构师) B <--> C(开发人员)
提高了决策效率;打破了部门壁垒;弱化了产品经理角色
领域驱动设计建议软件的所有参与方之间能以小组的形式进行直接沟通。开发要懂业务,业务方和产品也要懂技术。沟通的结果是形成一个大家都能认同和理解的领域语言。
系统组织架构
将所有业务领域划分为三大类型:核心领域、通用领域以及支持型领域
- 核心领域
- 所有组件看起来都很重要
- 一个业务是否是核心业务,取决于它是否能给公司带来行业内的竞争优势
- 三个要点
- 资源分配:需要有足够的时间和资源投资保持核心竞争力
- 审时度势:更具行业位置,判断竞争对手如何应对
- 宏观视角:是否能带来超额利润
- 通用领域
- 当市场上存在多个类似的产品,尽量采购产品或购买服务,而不是研发。(ROI)
- 支持型领域
- 来辅助核心领域正常运行的领域,比如会计系统、市场数据系统
- 是否可购买
- 是否市面上有这种产品,是否可人工
- 加入自研,保持和核心领域低耦合,随时替换
领域分析举例
资产管理系统的分析:
- 核心系统: 定价&风险管理
- 支持性系统:生命周期管理、交易
- 通用系统:日期变更、打印、支付、会计等系统