微服务架构设计基础之DDD领域驱动设计
程序员文章站
2022-03-03 09:31:35
理解=====“一层一模型”领域是与某个特定问题相关的知识和行为。一个领域本质上可以理解为就是一个问题域,只要是同一个领域,那问题域就相同。所以,只要我们确定了系统所属的领域,那这个系统的核心业务,即要解决的关键问题、问题的范围边界就基本确定了。一个领域有且只有一个核心问题,我们称之为该领域的「核心域」。在核心域、通用子域、支撑子域梳理的同时,会定义出子域中的「限界上下文」及其关系,用它来阐述子域之间的关系。界限上下文可以简单理解成一个子系统或组件模块。领域模块内部高内聚低耦合,具有清晰的业务边...
理解=====“一层一模型”
领域是与某个特定问题相关的知识和行为。一个领域本质上可以理解为就是一个问题域,只要是同一个领域,那问题域就相同。所以,只要我们确定了系统所属的领域,那这个系统的核心业务,即要解决的关键问题、问题的范围边界就基本确定了。
一个领域有且只有一个核心问题,我们称之为该领域的「核心域」。在核心域、通用子域、支撑子域梳理的同时,会定义出子域中的「限界上下文」及其关系,用它来阐述子域之间的关系。界限上下文可以简单理解成一个子系统或组件模块。
领域模块内部高内聚低耦合,具有清晰的业务边界
- 以「贫血模型」为基础的「事务脚本」的开发方式
- 以「充血模型」为基础的「领域驱动」的开发方式
贫血模型是指对象只用于在各层之间传输数据使用,只有数据字段和Get/Set方法,没有逻辑在对象中。而「事务脚本」可以理解为业务是由一条条增删改查的SQL组织而成,是面向过程的编程。
充血模型是面向对象设计的本质,一个对象是拥有状态和行为的。将大多数业务逻辑和持久化放在领域对象中,业务逻辑只是完成对业务逻辑的封装、事务、权限、校验等的处理。
领域层服务开发和设计的理念是关注自己的域,一旦边界划分清楚了,开发所需要考虑的永远都只是输入和输出,提供的服务一定是尽可能通用的,面向功能来开发的,而不是面向调用方来开发的。
本文地址:https://blog.csdn.net/qq_36993080/article/details/107344317
上一篇: JS实现单例模式的6种方案汇总
下一篇: vue递归实现三级菜单