业务分析之领域模型设计与面向业务设计分析

引入

作为一个程序员，在工作中经常会遇到新系统的系统分析与设计。如果突然某一个领导问你，或者要求你展示你的系统分析与设计时，你将如何展示？或者在面试的时候面试官问你你是如何分析设计？可能你的回答就是先深入分析需求，然后根据原型或者prd设计表与参数。然后再将业务进行拆解，来设计模块等等话语。但是当你回答完了以后你会发现你的领导或者面试都不知道如何往下接你话茬。不是说你说的有问题，而是你说的毫无水平，和没有说一样。那我们应该怎么去分析与设计呢？下面我将简单介绍一下我的方法。我们将以房地产领域住房保障项目为例（一个家庭，可以申请公租房、经济房、廉租房等）

首先我们将业务进行分析描述

主体对象：

保障家庭、保障人员

客体对象：

房屋

业务：

准入登记（保障家庭）、资格注销（保障家庭）、资格审核（保障家庭）、信息变更（保障家庭）、房源分配（保障家庭、房屋）、房屋互换（保障家庭、房屋）、房屋弃租（保障家庭、房屋），其他业务

业务要素：

全局参数、约束项、流程、业务参数、权限等

绝大多少业务你都可以按我上面的分析模式来说。这样说很容易在领导脑海中形成清晰的业务头绪。让领导认为你是一个有头脑，有经验的小伙子。

下面我们再进行程序设计描述
我们主要讲述俩种主流设计领域驱动设计与面向服务的设计方式。在我们平时的开发设计中，更多的是后者面向服务的设计。这2者有何区别呢？举个简单的示例用户，登录注册，上班干事等行为。

领域驱动模型：你创建一个userDomain类。类里面有登录，注册，上班等服务。 优势：利于业务理解，便于方法调用。劣势：内聚服务会过多。
面向服务：你会创建一个userLoginService,以及DoJobService 这2个服务类。优势：职责划分明确，便于协调开发。劣势：业务分离，很多时候调用层级混乱，力度更便宜具体业务。在领域设计中，将这一次可以提取到应用层中。
上面的示例我相信你一目了然其区别。

一、领域驱动设计（DDD）

领域建模：

通过领域建模，将业务系统中的关键概念和实体抽象为领域模型，以便更好地理解业务逻辑。

示例：保障家庭模型

1、实体

a.保障对象
b.家庭成员
c.财产信息

2、服务

a.创建保障家庭
b.修改保障家庭状态
c.保障家庭修改
d.保障家庭注销
e.查询保障对象

3、驱动事件

事件驱动架构是一种异步、高度解耦的软件架构，它将系统组件之间的通信转化为事件和事件处理器之间的通信。在这种架构中，系统组件通过发布和订阅事件来相互通信，而不是直接调用对方的方法。这种通信方式有助于提高系统的灵活性、可扩展性和可维护性。微服务系统中一般通过mq。
a.房源分配
b.房源弃租

领域驱动设计我个人认为只适合做业务分析，如果语言是java的话，其实代码我支持依旧按以往的方式来写，不要封装到一个类中，做到完全的高聚集。这样会导致边界很难去划分。同时也不符合我们高复用的设计初衷。

代码层次结构推荐使用

采用分层架构将系统划分为不同的层次，如展示层、应用层、领域层和基础设施层，以降低系统的耦合度并提高可维护性。

二、面向服务分析与设计（SOAD）

这个不做过多介绍，懂的都懂。不懂的再干2年就懂。