java架构-领域模型

什么是领域驱动设计?[面试6.0]

领域驱动设计(DDD,Domain-Driven Design),在软件开发前,通常需要进行大量的业务知识需要梳理,然后才到软件设计的层面,最后才是开发,而在业务知识梳理的过程中,我们必然会形成某个领域知识,根据领域知识来一步步驱动软件设计,这就是领域驱动设计的基本概念

为什么要用领域驱动模型?[面试6.0]

统一思想: 拥有统一语言,使得业务,产品,开发对问题的认知可得到统一
边界分离: 限界上下文用来区分业务边界,使得业务更加清晰
明确分工: 可以明确定义领域并形成团队分工
反映变化: 领域的变化相对于数据驱动更加及时

什么是领域,子域,界限上下文?[面试5.0]

领域子域和界限上下文
领域: 系统要解决的实际问题相关的所有东西的集合
领域模型: 将业务涉及的数据,流程,商业规则以面向对象的方式建立的一个模型
子域: 一个领域有多个子域(具体的项目实现),子域分为三种,都是根据业务来定义的
核心子域
支撑子域
通用子域
限界上下文: 领域模型的概念性边界,通用语言应用在边界内,即业务术语,代码中的类或方法等只要是相同的意思就使用相同的词汇,这样有助于团队快速理解,设计时应该尽量保证一个限界上下文一个子域

上下文映射图有哪些关系?[面试5.0]

上下文映射图是用来表示限界上下文怎么集成关联的
合作关系(partnership):
两个限界上下文的团队要么一起成功,要么一起失败,这两个团队就是一种合作关系
共享内核(shared kernel): 共享模型和代码(如jar),没有与另一个团队进行协商的情况下,共享模型和代码不能改变
客户方-供应方开发(customer-supplier development): 上下游关系,上游供应方提供给下游服务
遵奉者(跟随者)(conformist): 上游团队没有动力提供给下游团队的新需求而只能采用现有上游团队的服务
防腐层(anticorrupttion Layer, ACL): 放在下游上,该层作为上游系统的代理向下游系统提供服务,防腐层通过已有的接口与上游系统交互(API网关就是一个防腐层的实现)
开放主机服务(open host service, OHS): 定义一种协议,让你的子系统通过该协议来访问服务
发布语言(published language, PL): 发布一种共享语言完成集成交流(比如JSON),通常和开放主机服务一起使用
另谋他路(separate way): 两个限界上下文不存在任何关系,以便解耦
大泥球: 混杂在一起的模型

有哪些架构方式?[面试6.0]

领域分层架构
领域模型传统架构:
领域模型从接口层往下有应用层,领域层,基础设施层
严格分层架构(Strict Layers Architecture): 某层只能与直接位其下方的层发生耦合
松散分层架构(Relaxed Layers Architecture): 允许任意上方层与任意下方层发生耦合,比如有些直接调用基础设施层的数据

依赖倒置原则架构:
高层模块不依赖低层模块,两者都依赖于抽象
抽象不依赖于细节,细节应该依赖于抽象
简单的说: 接口定义在领域层,应用层,用户接口层,并让基础设施层实现这些接口

六边形分层架构:
内部六边形: 包括应用层(主要是业务逻辑),领域层
外部六边形: 包括应用驱动逻辑,基础设施
一个端口对应多个适配器,应用通过端口为外部提供服务,内部不关心外部实现
六边形架构的内部,外部各个层次可以独立做单元测试

命令和查询职责分离架构CQRS(Cammand-Query Responsibility Segregation):
CQRS将读和写分离,可以将读看做查询,写看做命令
查询时: 查询时只读数据,所有的方法都有返回值,且返回的数据就是界面需要的DTO
写数据时: 写数据时由于是发一个命令(Command),一般是修改对象状态,不返回数据,所以方法是void的,进行异步调用(消息队列)就更方便了
CQRS优势:
读写分离: 读写分离使用在读多写少的情况下,我们可以为读进行伸缩扩展来满足更高的并发
代码可集中管理: 由于读模式采用了Command,很方便定义一个CommandBus,然后将命令分发到每一个CommandHandler中进行处理

事件驱动架构(EDA):
一个生产者发布事件出来,其他服务可以使用这些事件来执行内部逻辑
事件驱动的优势:
异步: 没有阻塞,能将事件排队
松耦合: 生产者服务不需要对其他服务了解,生产者独立生产事件,消费者独立消费事件
易扩展: 可以跟踪瓶颈到特定服务,并扩展该服务即可
容灾支持: 事件驱动架构可以利用本地储存和重播来防止数据丢失
事件驱动的缺点:
事务较难管理,通常不支持ACID事务,需要使用分布式事务TCC,可靠消息最终一致性方案等保证

设计一个领域架构时有哪些建模方法?[面试6.0]

用例分析法:
获取用例: 提取领域规则描述
收集实体: 定位实体
添加关联: 两个实体间用动词关联起来
添加属性: 添加实体属性
模型精化: 可以用UML的泛化和组合来表达模型间的关系,同时可以做子领域的划分

四色建模法: 四色关注的是某个人的某角色在某个地点,时间用某物做了某事这种情况,他包括以下对象
时标型(Moment-Interval)对象: 具有可追溯性的记录运营或管理数据的时刻或时段对象,用粉红色表示
PPT(Party/Place/Thing)对象: 参与方/地点/物,用绿色表示
角色(Role)对象: 在时标型对象与PPT对象(通常是参与方)之间参与的角色,用黄色表示
描述(Description)对象: 对PPT对象的一种补充描述,用蓝色表示

事件风暴法: 类似头脑风暴,事件风暴注重于于可视化引导取得共识

领域模型中的实体是什么?[面试6.0]

实体: 具有唯一标识的业务对象,业务行为的改变可能对实体造成改变

领域模型中的值对象是什么?[面试6.0]

值对象: 指实体部分属性的打包
如: 用户的信息包括,姓名,地址,年龄,省市区等,若将省市区打包成的集合就是值对象

领域模型中的聚合是什么?[面试6.0]

聚合: 多个实体和值对象一起协同工作组成的集合,就是聚合,聚合是数据持久化和修改的基本单元

聚合根是什么?
是一个实体,该实体是聚合的管理者,代表了整个聚合

什么是领域服务?[面试6.0]

领域服务: 有些领域的操作是一些动词,并不能简单的把他们归类到某个实体或者值对象中,这样的操作行为可以声明成领域服务,领域服务就是为领域提供功能实现

什么是领域事件?[面试6.0]

领域事件: 领域中所发生的事情,这些事件可以由内部或外部限界上下文消费
领域事件优点: 可以将复杂的多事务处理任务进行分散成较小的逻辑单元,并且知道何时进行处理

什么是失血模型,贫血模型,充血模型,胀血模型?[面试6.0]

失血模型(POJO): 实体中只有属性和set,get方法不包含业务逻辑的处理部分,所有的业务处理部分交由Service处理
缺点: 重用性差

贫血模型: 实体包含普通业务处理部分,但不包含数据库持久化业务逻辑处理部分,其他的交给Service处理
优点: 结构清晰,易于实现和维护,一般还是采用这种模型
缺点: Service层的代码可能较多,重用性不如充血和胀血

充血模型: 实体包含普通业务处理部分和数据库持久化部分,少部分交给Service处理,Service较少DAO打交道
优点: 更加面向对象了,Service层很薄
缺点: 实体和Service比较混乱,不同开发程序员水平不齐,不好界定该分到实体还是Service

胀血模型: Service都不用,实体完全处理所有业务逻辑
缺点: 由于引入了对DAO层的操作,这些操作可能需要其他实体的支持,所以也会引入到当前实体中,实例化实体时会导致大量无用的实体信息暴露出来

实体之间有哪些关系?[面试6.0]

关联,聚合(组合),依赖,泛化(继承)