微服务工程以及领域驱动设计(DDD)的六个维度思考理解

领域驱动模型设计与微服务架构落地(二) 首先,既然我们的DDD是领域驱动设计。那么领域必然是我们的重中之重,那么什么是领域呢? 一个领域本质上可以理解为就是一个问题域,只要是同一个领域,那问题域就相同。所以,只要我们确定了系统所属的领域,那这个系统的核心业务,即要解决的关键问题、问题的范围边界就基本确定了。 通常我们说,要成为一个领域的专家,必须要在这个领域深入研究很多年才行。因为只有你研究了很多 年,你才会遇到非常多的该领域的问题,同时你解决这个领域中的问题的经验也非常丰富。 同时大家从字面上的意思也能够知道,领域其实就是我们的范围,而范围实际 阅读详情

1 整体思想

计算机领域有一句话:计算机中任何问题都可通过增加一个虚拟层解决。这句体现了分层思想重要性,分层思想同样适用于Java工程架构。

分层优点是每层只专注本层工作,可以类比设计模式单一职责原则,或者经济学比较优势原理,每层只做本层最擅长的事情。

分层缺点是层之间通信时,需要通过适配器,翻译成本层或者下层可以理解的信息,通信成本有所增加。

六个维度思考:

(1) 单一

每层只处理一类事情,满足单一职责原则

(2) 降噪

信息在每一层进行传输,满足最小知识原则,只向下层传输必要信息

(3) 适配

每层都需要一个适配器,翻译信息为本层或者下层可以理解的信息

(4) 纵向

纵向做隔离,同一个领域内业务要在本领域内聚

(5) 横向

横向做编排,应用层聚合多个领域进行业务编排

(6) 数据

数据对象尽量纯净,尽量使用基本类型

微服务的九层结构 

SpringBoot工程可以分成九层:

  • 工具层:util

  • 整合层:integration

  • 基础层:infrastructure

  • 领域层:domain

  • 应用层:application

  • 门面层:facade

  • 客户端:client

  • 控制层:controller

  • 启动层:boot

微服务与九层结构 

微服务和九层架构表述的是不同维度概念。微服务重点描述系统与系统之间交互关系,九层架构重点描述一个工程不同模块之间交互关系。

微服务架构设计通常分为前台、中台、后台:

第一点上图所有应用均可采用九层结构。

第二点中台应用承载核心逻辑,暴露核心接口,中台并不要理解所有端数据结构,而是通过client接口暴露相对稳定的数据。

第三点针对面向B端、面向C端、面向运营三种端,各自拆分出一个应用,在此应用中进行转换、适配和裁剪,并且处理各自业务。

第四点什么是大中台、小前台思想?中台提供稳定服务,前台提供灵活入口。

第五点如果后续要做秒杀系统,那么也可以理解其为一个前台应用(seckill-front)聚合各种中台接口。

2 分层详解 

创建项目:

user-demo-service
    -user-demo-service-application
    -user-demo-service-boot
    -user-demo-service-client
    -user-demo-service-controller
    -user-demo-service-domain
    -user-demo-service-facade
    -user-demo-service-infrastructure
    -user-demo-service-integration
    -user-demo-service-util

 2.1 util

工具层承载工具代码

不依赖本项目其它模块

只依赖一些通用工具包

user-demo-service-util
    -/src/main/java
        -date
            -DateUtil.java
        -json
            -JsonUtil.java
        -validate
            -BizValidator.java

2.2 infrastructure 

基础层承载数据访问和entity

同时承载基础服务(ES、Redis、MQ)

2.2.1 项目结构

user-demo-service-infrastructure
    -/src/main/java
        -base
            -service
                -redis
                    -RedisService.java
                -mq
                    -ProducerService.java
        -player
            -entity
                -PlayerEntity.java
            -mapper
                -PlayerEntityMapper.java
        -game
            -entity
                -GameEntity.java
            -mapper
                -GameEntityMapper.java
    -/src/main/resources
        -mybatis
            -sqlmappers
                -gameEntityMapper.xml
                -playerEntityMapper.xml

 2.2.2 本项目依赖

  • util

2.2.3 核心代码 

创建运动员数据表:

CREATE TABLE `player` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `player_id` varchar(256) NOT NULL COMMENT '运动员编号',
  `player_name` varchar(256) NOT NULL COMMENT '运动员名称',
  `height` int(11) NOT NULL COMMENT '身高',
  `weight` int(11) NOT NULL COMMENT '体重',
  `game_performance` text COMMENT '最近一场比赛表现',
  `creator` varchar(256) NOT NULL COMMENT '创建人',
  `updator` varchar(256) NOT NULL COMMENT '修改人',
  `create_time` datetime NOT NULL COMMENT '创建时间',
  `update_time` datetime NOT NULL COMMENT '修改时间',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8

运动员实体对象,gamePerformance字段作为string保存在数据库,体现了数据层尽量纯净,不要整合过多业务,解析任务应该放在业务层:

public class PlayerEntity {
    private Long id;
    private String playerId;
    private String playerName;
    private Integer height;
    private Integer weight;
    private String creator;
    private String updator;
    private Date createTime;
    private Date updateTime;
    private String gamePerformance;
}

运动员Mapper对象:

@Repository
public interface PlayerEntityMapper {
    int insert(PlayerEntity record);
    int updateById(PlayerEntity record);
    PlayerEntity selectById(@Param("playerId") String playerId);
}

2.3 integration

本层调用外部服务,转换外部DTO成为本项目可以理解对象。

2.3.1 项目结构

本项目调用用户中心服务:

user-demo-service-integration
    -/src/main/java
        -user
            -adapter
                -UserClientAdapter.java
            -proxy
                -UserClientProxy.java
            -vo                                    // 本项目对象
                -UserSimpleAddressVO.java
                -UserSimpleContactVO.java
                -UserSimpleBaseInfoVO.java

2.3.2 本项目依赖

  • util

2.3.3 核心代码

(1) 外部服务

// 外部对象
public class UserInfoClientDTO implements Serializable {
    private String id;
    private String name;
    private Date createTime;
    private Date updateTime;
    private String mobile;
    private String cityCode;
    private String addressDetail;
}

// 外部服务
public class UserClientService {

    // RPC
    public UserInfoClientDTO getUserInfo(String userId) {
        UserInfoClientDTO userInfo = new UserInfoClientDTO();
        userInfo.setId(userId);
        userInfo.setName(userId);
        userInfo.setCreateTime(DateUtil.now());
        userInfo.setUpdateTime(DateUtil.now());
        userInfo.setMobile("test-mobile");
        userInfo.setCityCode("test-city-code");
        userInfo.setAddressDetail("test-address-detail");
        return userInfo;
    }
}

(2) 本项目对象

// 基本对象
public class UserBaseInfoVO {
    private UserContactVO contactInfo;
    private UserAddressVO addressInfo;
}

// 地址值对象
public class UserAddressVO {
    private String cityCode;
    private String addressDetail;
}

// 联系方式值对象
public class UserContactVO {
    private String mobile;
}

(3) 适配器

public class UserClientAdapter {

    public UserBaseInfoVO convert(UserInfoClientDTO userInfo) {
        // 基础信息
        UserBaseInfoVO userBaseInfo = new UserBaseInfoVO();
        // 联系方式
        UserContactVO contactVO = new UserContactVO();
        contactVO.setMobile(userInfo.getMobile());
        userBaseInfo.setContactInfo(contactVO);
        // 地址信息
        UserAddressVO addressVO = new UserAddressVO();
        addressVO.setCityCode(userInfo.getCityCode());
        addressVO.setAddressDetail(userInfo.getAddressDetail());
        userBaseInfo.setAddressInfo(addressVO);
        return userBaseInfo;
    }
}

 (4) 调用外部服务

public class UserClientProxy {

    @Resource
    private UserClientService userClientService;
    @Resource
    private UserClientAdapter userIntegrationAdapter;

    // 查询用户
    public UserBaseInfoVO getUserInfo(String userId) {
        UserInfoClientDTO user = userClientService.getUserInfo(userId);
        UserBaseInfoVO result = userIntegrationAdapter.convert(user);
        return result;
    }
}

2.4 domain

2.4.1 概念说明

通过三组对比理解领域层:

  • 领域对象 VS 数据对象

  • 领域对象 VS 业务对象

  • 领域层 VS 应用层

(1) 领域对象 VS 数据对象

数据对象使用基本类型保持纯净:

public class PlayerEntity {
    private Long id;
    private String playerId;
    private String playerName;
    private Integer height;
    private Integer weight;
    private String creator;
    private String updator;
    private Date createTime;
    private Date updateTime;
    private String gamePerformance;
}

 领域对象需要体现业务含义:

public class PlayerQueryResultDomain {
    private String playerId;
    private String playerName;
    private Integer height;
    private Integer weight;
    private GamePerformanceVO gamePerformance;
}

public class GamePerformanceVO {
    // 跑动距离
    private Double runDistance;
    // 传球成功率
    private Double passSuccess;
    // 进球数
    private Integer scoreNum;
}

(2) 领域对象 VS 业务对象

业务对象同样会体现业务,领域对象和业务对象有什么不同?最大不同是领域对象采用充血模型聚合业务。

运动员新增业务对象:

public class PlayerCreateBO {
    private String playerName;
    private Integer height;
    private Integer weight;
    private GamePerformanceVO gamePerformance;
    private MaintainCreateVO maintainInfo;
}

 运动员新增领域对象:

public class PlayerCreateDomain implements BizValidator {
    private String playerName;
    private Integer height;
    private Integer weight;
    private GamePerformanceVO gamePerformance;
    private MaintainCreateVO maintainInfo;

    @Override
    public void validate() {
        if (StringUtils.isEmpty(playerName)) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
        if (null == height) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
        if (height > 300) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
        if (null == weight) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
        if (null != gamePerformance) {
            gamePerformance.validate();
        }
        if (null == maintainInfo) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
        maintainInfo.validate();
    }
}

(3) 领域层 VS 应用层 

第一个区别:领域层关注纵向,应用层关注横向。领域层纵向做隔离,本领域业务行为要在本领域内处理完。应用层横向做编排,聚合和编排领域服务。 

第二个区别:应用层可以更加灵活组合不同领域业务,并且可以增加流控、监控、日志、权限,分布式锁,相较于领域层功能更为丰富。

2.4.2 项目结构 

user-demo-service-domain
    -/src/main/java
        -base
            -domain
                -BaseDomain.java
            -event
                -BaseEvent.java
            -vo
                -BaseVO.java
                -MaintainCreateVO.java
                -MaintainUpdateVO.java
        -player
            -adapter
                -PlayerDomainAdapter.java
            -domain
                -PlayerCreateDomain.java          // 领域对象 
                -PlayerUpdateDomain.java
                -PlayerQueryResultDomain.java
            -event                                // 领域事件
                -PlayerUpdateEvent.java
                -PlayerMessageSender.java
            -service                              // 领域服务
                -PlayerDomainService.java
            -vo                                   // 值对象
                -GamePerformanceVO.java                
        -game
            -adapter
                -GameDomainAdapter.java        
            -domain
                -GameCreateDomain.java
                -GameUpdateDomain.java
                -GameQueryResultDomain.java
            -service
                -GameDomainService.java

2.4.3 本项目依赖

  • util

  • client

领域对象需要业务校验所以依赖client模块:

  • BizException

  • ErrorCodeBizEnum

2.4.4 核心代码 

// 修改领域对象
public class PlayerUpdateDomain extends BaseDomain implements BizValidator {
    private String playerId;
    private String playerName;
    private Integer height;
    private Integer weight;
    private String updator;
    private Date updatetime;
    private GamePerformanceVO gamePerformance;
    private MaintainUpdateVO maintainInfo;

    @Override
    public void validate() {
        if (StringUtils.isEmpty(playerId)) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
        if (StringUtils.isEmpty(playerName)) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
        if (null == height) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
        if (height > 300) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
        if (null == weight) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
        if (null != gamePerformance) {
            gamePerformance.validate();
        }
        if (null == maintainInfo) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
        maintainInfo.validate();
    }
}

// 比赛表现值对象
public class GamePerformanceVO implements BizValidator {

    // 跑动距离
    private Double runDistance;
    // 传球成功率
    private Double passSuccess;
    // 进球数
    private Integer scoreNum;

    @Override
    public void validate() {
        if (null == runDistance) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
        if (null == passSuccess) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
        if (Double.compare(passSuccess, 100) > 0) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
        if (null == runDistance) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
        if (null == scoreNum) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
    }
}

// 修改人值对象
public class MaintainUpdateVO implements BizValidator {

    // 修改人
    private String updator;
    // 修改时间
    private Date updateTime;

    @Override
    public void validate() {
        if (null == updator) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
        if (null == updateTime) {
            throw new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT);
        }
    }
}

// 领域服务
public class PlayerDomainService {

    @Resource
    private UserClientProxy userClientProxy;
    @Resource
    private PlayerRepository playerEntityMapper;
    @Resource
    private PlayerDomainAdapter playerDomainAdapter;
    @Resource
    private PlayerMessageSender playerMessageSender;

    public boolean updatePlayer(PlayerUpdateDomain player) {
        AssertUtil.notNull(player, new BizException(ErrorCodeBizEnum.ILLEGAL_ARGUMENT));
        player.validate();

        // 更新运动员信息
        PlayerEntity entity = playerDomainAdapter.convertUpdate(player);
        playerEntityMapper.updateById(entity);

        // 发送更新消息
        playerMessageSender.sendPlayerUpdatemessage(player);

        // 查询用户信息
        UserSimpleBaseInfoVO userInfo = userClientProxy.getUserInfo(player.getMaintainInfo().getUpdator());
        log.info("updatePlayer maintainInfo={}", JacksonUtil.bean2Json(userInfo));
        return true;
    }
}

2.5 application 

本层关注横向维度聚合领域服务,引出一种新对象称为聚合对象。因为本层需要聚合多个维度,所以需要通过聚合对象聚合多领域属性,例如提交订单需要聚合商品、物流、优惠券多个领域。

// 订单提交聚合对象
public class OrderSubmitAgg {

    // userId
    private String userId;

    // skuId
    private String skuId;

    // 购买量
    private Integer quantity;

    // 地址信息
    private String addressId;

    // 可用优惠券
    private String couponId;
}

// 订单应用服务
public class OrderApplicationService {

    @Resource
    private OrderDomainService orderDomainService;
    @Resource
    private CouponDomainService couponDomainService;
    @Resource
    private ProductDomainService productDomainService;

    // 提交订单
    public String submitOrder(OrderSubmitAgg orderSumbitAgg) {

        // 订单编号
        String orderId = generateOrderId();

        // 商品校验
        productDomainService.queryBySkuId(orderSumbitAgg.getSkuId());

        // 扣减库存
        productDomainService.subStock(orderSumbitAgg.getStockId(), orderSumbitAgg.getQuantity());

        // 优惠券校验
        couponDomainService.validate(userId, couponId);

        // ......

        // 创建订单
        OrderCreateDomain domain = OrderApplicationAdapter.convert(orderSubmitAgg);
        orderDomainService.createOrder(domain);
        return orderId;
    }
}

2.5.1 项目结构

user-demo-service-application
    -/src/main/java
        -player
            -adapter
                -PlayerApplicationAdapter.java
            -agg
                -PlayerCreateAgg.java
                -PlayerUpdateAgg.java
            -service
                -PlayerApplicationService.java
        -game
            -listener
                -PlayerUpdateListener.java            // 监听运动员更新事件

2.5.2 本项目依赖

  • util

  • domain

  • integration

  • infrastructure

2.5.3 核心代码

本项目领域事件交互使用EventBus框架:

// 运动员应用服务
public class PlayerApplicationService {

    @Resource
    private LogDomainService logDomainService;
    @Resource
    private PlayerDomainService playerDomainService;
    @Resource
    private PlayerApplicationAdapter playerApplicationAdapter;

    public boolean updatePlayer(PlayerUpdateAgg agg) {
        // 运动员领域
        boolean result = playerDomainService.updatePlayer(agg.getPlayer());
        // 日志领域
        LogReportDomain logDomain = playerApplicationAdapter.convert(agg.getPlayer().getPlayerName());
        logDomainService.log(logDomain);
        return result;
    }
}

// 比赛领域监听运动员变更事件
public class PlayerUpdateListener {

    @Resource
    private GameDomainService gameDomainService;

    @PostConstruct
    public void init() {
        EventBusManager.register(this);
    }

    @Subscribe
    public void listen(PlayerUpdateEvent event) {
        // 更新比赛计划
        gameDomainService.updateGameSchedule();
    }
}

 2.6 facade + client

设计模式中有一种Facade模式,称为门面模式或者外观模式。这种模式提供一个简洁对外语义,屏蔽内部系统复杂性。

client承载数据对外传输对象DTO,facade承载对外服务,必须满足最小知识原则,无关信息不必对外透出。这样做有两个优点:

  • 简洁性:对外服务语义明确简洁

  • 安全性:敏感字段不能对外透出

2.6.1 项目结构

(1) client

user-demo-service-client
    -/src/main/java
        -base
            -dto
                -BaseDTO.java
            -error
                -BizException.java
                -BizErrorCode.java
            -event
                -BaseEventDTO.java
            -result
                -ResultDTO.java
        -player
            -dto
                -PlayerCreateDTO.java
                -PlayerQueryResultDTO.java
                -PlayerUpdateDTO.java
            -enums
                -PlayerMessageTypeEnum.java
            -service
                -PlayerClientService.java

 (2) facade

user-demo-service-facade
    -/src/main/java
        -player
            -adapter
                -PlayerFacadeAdapter.java
            -impl
                -PlayerClientServiceImpl.java
        -game
            -adapter
                -GameFacadeAdapter.java
            -impl
                -GameClientServiceImpl.java

2.6.2 本项目依赖

client不依赖本项目其它模块,这一点非常重要:因为client会被外部引用,必须保证本层简洁和安全。facade依赖本项目三个模块:

  • domain

  • client

  • application

2.6.3 核心代码

 (1) DTO

以查询运动员信息为例,查询结果DTO只封装强业务字段,运动员ID、创建时间、修改时间等业务不强字段无须透出:

public class PlayerQueryResultDTO implements Serializable {
    private String playerName;
    private Integer height;
    private Integer weight;
    private GamePerformanceDTO gamePerformanceDTO;
}

(2) 客户端服务

public interface PlayerClientService {
    public ResultDTO<PlayerQueryResultDTO> queryById(String playerId);
}

(3) 适配器

public class PlayerFacadeAdapter {

    // domain -> dto
    public PlayerQueryResultDTO convertQuery(PlayerQueryResultDomain domain) {
        if (null == domain) {
            return null;
        }
        PlayerQueryResultDTO result = new PlayerQueryResultDTO();
        result.setPlayerId(domain.getPlayerId());
        result.setPlayerName(domain.getPlayerName());
        result.setHeight(domain.getHeight());
        result.setWeight(domain.getWeight());
        if (null != domain.getGamePerformance()) {
            GamePerformanceDTO performance = convertGamePerformance(domain.getGamePerformance());
            result.setGamePerformanceDTO(performance);
        }
        return result;
    }
}

(4) 服务实现

本层可以引用applicationService,也可以引用domainService,因为对于查询等简单业务场景,没有多领域聚合,可以直接使用领域服务。

public class PlayerClientServiceImpl implements PlayerClientService {

    @Resource
    private PlayerDomainService playerDomainService;
    @Resource
    private PlayerFacadeAdapter playerFacadeAdapter;

    @Override
    public ResultDTO<PlayerQueryResultDTO> queryById(String playerId) {
        PlayerQueryResultDomain resultDomain = playerDomainService.queryPlayerById(playerId);
        if (null == resultDomain) {
            return ResultCommonDTO.success();
        }
        PlayerQueryResultDTO result = playerFacadeAdapter.convertQuery(resultDomain);
        return ResultCommonDTO.success(result);
    }
}

2.7 controller

facade服务实现可以作为RPC提供服务,controller则作为本项目HTTP接口提供服务,供前端调用。

controller需要注意HTTP相关特性,敏感信息例如登陆用户ID不能依赖前端传递,登陆后前端会在请求头带一个登陆用户信息,服务端需要从请求头中获取并解析。

2.7.1 项目结构

user-demo-service-controller
    -/src/main/java
        -controller
            -player
                -PlayerController.java
            -game
                -GameController.java

2.7.2 本项目依赖

  • facade

2.7.3 核心代码

@RestController
@RequestMapping("/player")
public class PlayerController {

    @Resource
    private PlayerClientService playerClientService;

    @PostMapping("/add")
    public ResultDTO<Boolean> add(@RequestHeader("test-login-info") String loginUserId, @RequestBody PlayerCreateDTO dto) {
        dto.setCreator(loginUserId);
        ResultCommonDTO<Boolean> resultDTO = playerClientService.addPlayer(dto);
        return resultDTO;
    }

    @PostMapping("/update")
    public ResultDTO<Boolean> update(@RequestHeader("test-login-info") String loginUserId, @RequestBody PlayerUpdateDTO dto) {
        dto.setUpdator(loginUserId);
        ResultCommonDTO<Boolean> resultDTO = playerClientService.updatePlayer(dto);
        return resultDTO;
    }

    @GetMapping("/{playerId}/query")
    public ResultDTO<PlayerQueryResultDTO> queryById(@RequestHeader("test-login-info") String loginUserId, @PathVariable("playerId") String playerId) {
        ResultCommonDTO<PlayerQueryResultDTO> resultDTO = playerClientService.queryById(playerId);
        return resultDTO;
    }
}

 2.8 boot

boot作为启动层承载启动入口

2.8.1 项目结构

user-demo-service-boot
    -/src/main/java
        -com.user.demo.service
            -MainApplication.java

2.8.2 依赖本项目

  • 所有模块

2.8.3 核心代码 

@MapperScan("com.user.demo.service.infrastructure.*.mapper")
@SpringBootApplication
public class MainApplication {
    public static void main(final String[] args) {
        SpringApplication.run(MainApplication.class, args);
    }
}

3 文章总结

3.1 六个维度

(1) 单一

每层只处理一类事情,util只承载工具对象,integration只处理外部服务,每层职责单一且清晰

(2) 降噪

如无必要勿增实体,例如查询结果DTO只透出最关键字段,例如运动员ID、创建时间、修改时间等业务不强字段无须透出

(3) 适配

service、facade、intergration层都存在适配器,翻译信息为本层或者下层可以理解的信息

(4) 纵向

domain service内聚本领域业务

(5) 横向

application service编排多个领域业务

(6) 数据

数据对象要纯净,尽量使用基本类型

3.2 微服务的九层结构

微服务和九层结构表述的是不同维度概念。微服务重点描述系统与系统之间交互关系,九层结构重点描述一个工程不同模块之间交互关系,这一点一定要注意区分。

万字长文助你上手软件领域驱动设计 DDD 作者:faryrong,腾讯 CSIG 后台开发工程师最近看了一本书《解构-领域驱动设计》,书中提出了领域驱动设计统一过程(DDDRUP),它指明了实践 DDD 的具体步骤,并很好地串联了各种概念、模式和思想。因此,我对书本内容做了梳理、简化,融入自己的理解,并结合之前阅读的书籍以及实践经验,最终形成这篇文章。希望可以帮助大伙理顺 DDD 的各种概念、模式和思想,降低上手... 阅读详情

相关推荐

简析DDD(领域驱动设计)及落地

DDD(领域驱动设计)是对软件所涉及到的领域进行建模,以应对系统规模过大时引起的软件复杂性的问题。而在微服务微应用蔚然成风的今天,他们共同体现的分而治之的思想,使得领域建模显得尤为重要。 一、简析DDD DDD溯源 在早期开发中,领域模型就是数据库设计,但是传统的开发存在一定问题。 (1)Service层很重,所有逻辑处理基本都放在service层。 (2)POJO作为 Service 层非常重要的一个实体,因为不同场景的需求做不同的变化和组合,造成 POJO 的几种不同模型(失血、贫血、充血)。 (3

YG_ECP的博客 1274

微服务和领域驱动

微服务设计 领域驱动设计

penn 2037

一层一责,一聚合一包:DDD分层架构下的微服务代码模型、三重边界与服务数据协作

领域模型画得再清楚,落不进代码也是空谈。本文以一个可运行的客户中心微服务为线索,先对比整洁架构、六边形架构与DDD分层架构,指出三者共同守护的那条隔离核心业务的红线;再把DDD分层落成四个一级目录、以聚合为单位分包、一个聚合一个仓储的代码模型,拆解实体、聚合根、值对象、领域事件、领域服务与仓储的设计要点;随后厘清逻辑、物理、代码三重边界,并用检查器实测:干净代码零越界,拆出积分聚合时领域代码无需改动;注入九处越界后,必须先重构才能拆分。最后梳理服务调用三场景与PO、DO、DTO、VO的协作。

曾经“等你生日那天”都遥远得像未来,如今却可欢愉的挥手说“下个十年见” 177万+

领域驱动设计(DDD)详解:微服务拆分神器

(写和读的责任分离)Command:执行动作,返回void。(行动可能会改变聚合、实体、值对象的内容)Query:只查询,不修改对象状态。适用CQRS的风格:事件驱动系统风格、管道过滤器风格。领域驱动设计中,对外提供功能的只有聚合根的功能,聚合根里面的实体尽量只对聚合根提供服务。聚合根的子对象,尽量都用实体对象封装。

秃了也弱了 5865

微服务架构设计基础之领域驱动设计

本文来自oschina,文章主要介绍了介绍了微服务设计基础或架构模型:领域驱动设计和立方体模型等相关内容。微服务现在可以说是软件研发领域无人不提的话题,然而业界流行的对比多数都是所谓的Monolithic(单体应用),而大量的系统在十几年前都已经是以SOA(面向服务架构)为基础的分布式系统了,那么微服务作为新的架构标准与SOA有什么差异点呢?其本质区别在于设计原理,微服务是去中心化设计,SOA是「集成」形成中心设计;另外,笔者认为以下几点并不是微服务和SOA的区别点:CI/CD:持续集成、持续部署本身与敏捷、DevOps是交织在一起的,CI\CD更倾向于软件工程的领域,与微服务无关;基于容器还

手把手排查IOMMU映射故障:从内核日志到硬件寄存器调试全指南

本文详细解析了IOMMU映射故障的排查方法,从内核日志分析到硬件寄存器调试,提供了一套完整的诊断流程。涵盖AMD和Intel平台的特定调试技巧,包括ATS协商失败、DMA传输错误等常见问题的解决方案,并介绍了高级调试工具链的搭建与性能优化策略。

weixin_42666036的博客 353

猿创征文|微服务架构领域驱动设计(DDD)

领域驱动设计是提供了一种解决问题的方法,提出这种方法的时候也给我设想了这个方法所能达到或者实现的某种结果

剑飞的架构思维 1013

西门子S7-200 SMART与施耐德ATV变频器Modbus通讯实战:从接线到稳定运行的完整指南

本文详细介绍了西门子S7-200 SMART PLC与施耐德ATV变频器之间实现稳定Modbus通讯的完整实战指南。内容涵盖从硬件接线、参数配置、PLC程序编写到触摸屏设计的全流程,并分享了提升通讯稳定性的关键技巧和常见故障排查方法,助力工业自动化系统可靠运行。

kkk56的博客 1104

六个思考维度:DDD + SpringBoot工程九层结构图解与实战

微服务和九层结构表述的是不同维度概念。微服务重点描述系统与系统之间交互关系,九层结构重点描述一个工程不同模块之间交互关系

JAVA前线技术专栏 9189

【开源训练数据集2】10个最适合机器学习的股票市场数据集

​随着加密货币在世界各地的兴起,人们现在有比以往更多的投资方式。然而,这并不像低买高卖那么简单。如果你能准确预测股市,你就会成为地球上最富有的人之一。因此,之前已经有关于如何利用情绪分析来预测股市的研究。对于那些希望构建类似预测模型的人,本文将介绍 10 个用于机器学习的股票市场和加密货币数据集。

u010542847的博客 2138

SDU CS 期末考回忆版合集

删除原有分散的版本,合订起来画个。包括:机器学习、算法、图形学、操作系统、编译原理、软件工程、大数据分析管理、计算机体系结构等。

https://github.com/ZhaoyungZhang 6647

30分钟快速了解DDD!DDD领域驱动设计入门及案例讲解(图文并茂+浅显易懂)

从为什么要使用DDD领域驱动设计模型,到DDD中的常见概念说明,如何实施DDD以及结合实际案例说明DDD的使用方式。

月月工作室的博客 4095

AutoCAD2016安装破解教程

AutoCAD2016安装破解教程。本人亲自实验,破解成功,有效。以64位为例。 工具/原料   笔记本电脑 AutoCAD2016安装包 AutoCAD2016注册机(xf-adsk2016_x64.exe)链接:http://pan.baidu.com/s/1cAZQA windows7/8/8.1/10-32...

weixin_33804990的博客 1万+

领域驱动设计(DDD)实现之路

前言 2004年,当Eric Evans的那本《领域驱动设计——软件核心复杂性应对之道》(后文简称《领域驱动设计》)出版时,我还在念高中,接触到领域驱动设计(DDD)已经是8年后的事情了。那时,我正打算在软件开发之路上更进一步,经同事介绍,我开始接触DDD。 我想,多数有经验的程序开发者都应该听说过DDD,并且尝试过将其应用在自己的项目中。不知你是否遇到过这样的场景:你创建了一个资源库(Repos...

w 7141

从CMT2300A实战出发:Sub1G射频匹配电路设计要点与315MHz应用详解

本文从CMT2300A芯片实战出发,详细解析Sub1G射频匹配电路设计要点,特别针对315MHz应用场景。内容涵盖频段划分逻辑、调制方式选择、晶体振荡器设计等基础认知,以及315MHz匹配电路物料选型、巴伦网络处理等实战技巧,并分享PCB布局防干扰设计和实测验证方法,助力开发者优化射频通信性能。

weixin_29238147的博客 162

yolov8x-p2 实现 tensorrt 推理

yolov8x-p2, tensorrt 实现.

J。 2273

DDD领域驱动设计

一. 什么是DDD 2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software (领域驱动设计),简称Evans DDD。Evans DDD是一套综合软件系统分析和设计的面向对象建模方法。 领域驱动设计分为两个阶段: 1.以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互...

zhoxing 1万+

基于Simulink的伺服电机位置闭环控制仿真

本文带你从零构建了伺服电机位置闭环控制系统​ 的完整Simulink仿真模型,实现了:✅ 搭建PMSM伺服电机、逆变器、机械臂负载的主电路与编码器反馈模型;✅ 用MATLAB Function实现三环控制(位置环PID、坐标变换、电流环PI);✅ 验证阶跃定位(稳态误差0.002°、响应0.08s)与正弦跟踪(误差0.008°)的高性能;✅ 对比开环控制,明确位置闭环在精度、响应、抗扰上的优势;✅ 理解“三环嵌套+反馈校正”的核心思想(精密定位的工程实现)。核心收获。

amy_mhd的博客 173

DDD领域驱动设计内容分享(二十):从美团抽奖平台,看DDD在大厂如何落地?

同时,我们的表格也是一个包含大量字段的订单大表。当业务规模庞大到一定程度,编排本身就富含了业务逻辑(除此之外,应用服务在稳定性、性能方面所做的措施也希望统一起来,而非散落各处),那么此时应用服务对于外部来说是一个领域服务,整体看起来则是一个独立的限界上下文。在抽奖上下文中,我们通过抽奖(DrawLottery)这个聚合根来控制抽奖行为,可以看到,一个抽奖包括了抽奖ID(LotteryId)以及多个奖池(AwardPool),而一个奖池针对一个特定的用户群体(UserGroup)设置了多个奖品(Award)

之乎者也·的博客 1808

汉书HE8,好用的汇编代码编写工具

汉书HE8,好用的汇编代码编写工具早期编写汇编代码所用功能强大

Outlook Express 6 (OE6) for Win7/Win8/Win10

英文版 Outlook Express6.0, 兼容Win7/Win10/WinXP,解压就可用。

DDD与微服务架构浅析

代码精选(www.codehuber.com),程序员的终身学习网站已上线!后端技术】、【前端领域】感兴趣的小可爱,也欢迎关注❤️❤️❤️ 【JavaGPT】❤️❤️❤️,我将会给你带来巨大的【收获与惊喜】💝💝💝!

JavaGPT的博客 964

pscad IEEE标准系统搭建说明

pscad IEEE标准系统搭建说明,包含典型的IEEE 9节点、14节点、30节点、39节点和118节点系统。内含标准测试系统的原始数据和潮流结果。

DDD领域驱动设计内容分享(三十二):DDD领域建模实战——四色建模法

其实很简单,我们需要一个载体,去把思考的过程沉淀下来,等到产品经理来找我们加需求评估影响范围的时候,新人入职给他讲解业务的时候,通过这个载体就能直观地呈现出来,这就是DDD设计呈现的魅力所在。如果业务经过战略设计合理去划分,每个业务的业务边界会显得特别清晰,即使我们的代码没有使用DDD的思想去完成搭建,即使我们还是使用传统的MVC架构,也不会影响业务正常运作,业务的通用语言有它的业务边界,我们不大可能用一个简单的术语没有歧义地去描述一个复杂的业务领域,BC就是用来细分领域,从而定义通用语言所在的边界。

之乎者也·的博客 3116

IMSL CNL 7.0.0 (x86-64)Crack

IMSL CNL 7.0.0 (x86-64)Crack intel的算法库破解文件,这是C++版本的破解文件

DDD概念:之一领域驱动设计(DDD)是什么?

DDD不是银弹,而是持续探索业务本质的旅程。深入理解业务——与领域专家共同建模拥抱变化——通过限界上下文隔离变更影响保持谦逊——承认没有一劳永逸的设计正如Eric Evans所说:“优秀的软件不是构建出来的,而是演化出来的。从今天开始,尝试用DDD的视角重新审视你的系统,或许会发现一片新大陆。

2401_83923080的博客 1570

DDD 概念理解-理论篇

领域驱动设计(Domain Driven Design,DDD),DDD为我们提供了一种架构设计方法,既面向业务,又面向技术,从业务需求到领域建模,从领域服务到技术转化,强调开发人员与领域专家协同。DDD的核心思想是业务与技术相结合的一种过程,既强调业务的理解,又强调应用领域建模方法的使用。DDD本质上是面向对象分析的扩展和延伸,它基于面向对象分析技术进行了分层规划,同时对其中的核心概念和划分做了详细的指引。(理解是更深层次、全面的面相对象思维)

哎幽的成长 2238

DDD为什么能火起来?DDD 与微服务到底是啥关系!

来源:https://www.cnblogs.com/Courage129/p/14839544.htmlDDD为什么能火起来?我们先不讨论DDD的定义, 先梳理一下DDD火起来的背景, ...

架构文摘 975

DDD领域驱动设计内容分享(十三):京东的微服务生产项目,DDD如何落地?

现在对于一个后端开发工程师来说,微服务,DDD都是挂在嘴边的东西,感觉大家接触到多,也了解的多。然而,个人对微服务架构的理解却如同我小时候读《三国演义》,随着年龄和经验的增长,感受也各不相同。微服务对于开发人员而言,如同千面镜,每个人看到的风景都独具特色。基于此,我想结合自己的业务实践,分享一下在微服务架构实践过程中的心路历程。在笔者看来,微服务架构并没有一个准确的定义,但他会有很多特征,通过描述他的特征用来把控它是什么。

之乎者也·的博客 1289
上一篇: SpringBoot中解决Redis的缓存穿透、缓存击穿、缓存雪崩案例
下一篇: 账户中心四个账户设计案例
splendor.s
博客等级 码龄10年 91粉丝 67原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值