当前位置 : 首页 » 文章分类 :  开发  »  领域驱动设计

领域驱动设计

Domain Driven Design 领域驱动设计

贫血模型和充血模型

贫血模型:domain 中只有数据,没有任何业务逻辑。
充血模型:domain 中除了承载数据的属性外,还有和其职责相关的方法。

充血模型把对象和行为封装在一起,贫血模型对象只包含数据,操作数据的行为写在别的类中。

充血模型是有血有肉的,核心领域方法都放到模型中去,而不是把领域方法放到模型之上的service层中去。

贫血模型与充血模型的对比
http://www.ituring.com.cn/article/125

充血模型与贫血模型分别适用于何种情况?
https://www.zhihu.com/question/20360521

javaEye上面对于domain object的讨论
http://www.blogjava.net/GandofYan/archive/2006/05/30/48954.html

贫血症引起的失忆症

领域驱动设计在互联网业务开发中的实践 - 美团技术团队
https://tech.meituan.com/2017/12/22/ddd-in-practice.html

Controller与Service及如何分层

那些年,我们见过的 Java 服务端乱象
https://mp.weixin.qq.com/s/I_pfVRYLv5hlBA2JgAQxEQ

一个微服务+DDD(领域驱动设计)的代码结构示例
https://www.cnblogs.com/ealenxie/p/9559781.html

java项目 service层和biz层的区别

我们项目一直只有service层,这次看到别人项目中多了biz层,说也是业务逻辑层,熟悉的同学能不能讲一讲和service层的区别和好处?

如果是贫血模式 就不是多此一举

项目前期 或者小项目没什么太大区别
但是项目大了以后 区别就很大了

项目开发到后期的话 你一个项目内包含有其他的小项目 比如 后台 erp 商城 等等 都用的是同一个数据库
这个时候 就不能使用一个service/biz 全部解决了 有些业务是通用的 有一些业务可能只有erp有 其他模块没有 也有可能同一个业务 在细微上有一些差别 如果全部都放进一个业务层中的话 这个业务层就会非常的臃肿
这个时候就需要拆分:一个基础业务层 一个应用层业务层
基础业务层只是针对该对象的CURD操作,应用业务层就是一个复杂的功能模块或流程

举个例子 service作基础业务层 biz作为应用层业务层
比如我现在要在商城中 做一个下单功能 牵涉到商品,库存,活动等等 那么我把这个东西放哪呢? 订单service层? 如果放到这里 订单service层中就会引入商品,库存,活动的service或dao 如果还有其他功能 那么这个模块牵涉到的功能就越来越多 所以并不合适 不光商城中牵涉到订单service 后台也可能会用到 erp也可能会用到 那么这时候就需要做个一个应用层

可以去了解一下 DDD 领域驱动设计

java项目 service层和biz层的区别
https://segmentfault.com/q/1010000011544892/a-1020000012198541

manager 层

Manager 层最早出自阿里开发规约:
Web层(Controller层) -> Service层(业务逻辑) -> Manager层(通用处理层) -> DAO层(持久化访问)

Manager 层功能:
1、对第三方平台封装的层,预处理返回结果及转化异常信息。
2、对 Service 层通用能力的下沉,如缓存方案、中间件通用处理。
3、与 DAO 层交互,对多个 DAO 的组合复用。

Manager 层与 Service 层关系:
Manager 层提供原子的服务接口,Service 层负责依据业务逻辑来编排原子接口。

entity/model/domain区别

1、entity 字段必须和数据库字段一样,一个 entity 对应一张表
2、model 对应前端展示层,model 中的字段会直接在前端展示
3、domain 域,代表一个对象模块,一个 domain 中的字段可能横跨多个 entity,有多个 entity 实体字段组合而成

防腐层

防腐层(Anti-corruption layer),DDD(Eric Evans)中引入的模式, 用于隔离两个系统, 允许两个系统之间在不知道对方领域知识的情况下进行集成。

主要进行的是两个系统之间的model(模型)或者协议的转换, 并且最终目的是为了系统使用者的方便而不是系统提供者的方便, 进一步解释就是ACL尽量把系统提供者的模型转换为系统使用者的模型(而不引入中间第三者模型)

使用场景:
新旧系统切换时, 有些新系统需要和旧系统打交道, 此时可以利用 防腐层隔离新旧系统。
微服务中多个边界上下文的领域知识需要共享, 可以利用防腐层隔离两个系统

设计模式的实现:
Facade
Adapter

DDD 分层架构

上一篇 HTTP

下一篇 同源策略和CORS跨域

阅读
评论
1.2k
阅读预计4分钟
创建日期 2019-02-18
修改日期 2019-06-24
类别
标签

页面信息

location:
protocol:
host:
hostname:
origin:
pathname:
href:
document:
referrer:
navigator:
platform:
userAgent:

评论