基于DDD的微服务架构设计

标签: ddd 微服务 架构 | 发表时间:2016-07-20 17:19 | 作者:
出处:http://www.iteye.com

DDD领域驱动设计(DDD:Domain-Driven Design)

架构背景:

    现有的架构设计实在受不了,业务的反反复复地变化,导致代码圈复杂度之深让人恐惧。之前的微服务架构经验让我更加彻底点,采用DDD领域驱动设计进行整个改变。

    随着经过几个月的努力,确实慢慢地体会到ddd的架构设计的优势,聚合根设计能够协助我们整个服务改造,开发起来越来越迅速。



 

CQRS访问方式:



 在CQRS的架构体系,首先会被独立出来两个组件,一个事command的微服务负责add、update等改变状态的动作,query的微服务顾名思义就是读动作。


  • 微服务采用spring-boot框架
  • 构建、运行采用docker容器
  • CQRS的axon、eventbus,存储采用elasticsearch
  • gateway采用自主研发的方式,支持注册、发现、路由方式

案例:

gateway在之前的blog已经写过,不在这里叙述

首先简单的rest controller

@RestController
public class NotifyController {

    @Autowired
    private CommandGateway commandGateway;


    @RequestMapping(value = "/notify", method = RequestMethod.GET)
    public void notify(HttpServletRequest request) {
        commandGateway.send(asCommandMessage(new CreateTaskCommand("1","chenyang","China")),
                new CommandCallback() {
                    @Override
                    public void onSuccess(Object result) {
                        //成功继续事情
                    }
                    @Override
                    public void onFailure(Throwable cause) {
                        //失败
                    }
                });
    }
}

 Command:

public class SuccessNotification  extends AbstractAnnotatedAggregateRoot<String>

    {
        /**
         * The constant serialVersionUID
         */
        private static final long serialVersionUID = -159779842362041665L;

        @AggregateIdentifier
        private String id;

        @CommandHandler
        public SuccessNotification(SuccessNotifyCommand command) {
        apply(new SuccessNotifyEvent(command.getId()));
    }

        SuccessNotification() {
    }


        @CommandHandler
        void  on(SuccessNotifyCommand command) {
        apply(new SuccessNotifyEvent(command.getId()));
    }


        @EventSourcingHandler
        public void on(SuccessNotifyEvent event) {
            this.id = event.getId();
        }
}

 Event:

	@EventHandler
	String on(SuccessNotifyEvent event) {
		return "world";
	}

 

最终结论:

   相对于烟囱式的方式,ddd对于开发者以及架构师要求更高,充当角色之一领域专家,需要对于聚合根理解透彻,才能更好地理解业务。

 



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [ddd 微服务 架构] 推荐:

基于DDD的微服务架构设计

- - ITeye博客
DDD领域驱动设计(DDD:Domain-Driven Design).     现有的架构设计实在受不了,业务的反反复复地变化,导致代码圈复杂度之深让人恐惧. 之前的微服务架构经验让我更加彻底点,采用DDD领域驱动设计进行整个改变.     随着经过几个月的努力,确实慢慢地体会到ddd的架构设计的优势,聚合根设计能够协助我们整个服务改造,开发起来越来越迅速.

为什么在做微服务设计的时候需要DDD?

- - DockOne.io
记得之前在规划和设计微服务架构的时候,张队长给了我一个至今依然记忆深刻的提示:『你的设计蓝图里为什么没有看到DDD的影子呢. 随着对充血模型的领域认知的加深,我越加感觉到DDD的重要性. 但是DDD内容繁多,是不是要深入去了解呢,我觉得不必入坑太深,个人浅见,它最核心的一点就是针对贫血模型的不足而设计,把原先传统的贫血模型里的业务逻辑层拎出来,融入到Domain层,这样面对复杂业务的规模化变更,我们只需要专注于Domain即可.

用DDD指导微服务拆分 - ThoughtWorks洞见

- -
对于服务拆分的逻辑来说,是先设计高内聚低耦合的领域模型,再实现相应的分布式系统. 服务的划分有一些基本的方法和原则,通过这些方法能让微服务划分更有操作性. 最终在微服务落地实施时也能按图索骥,无论是对遗留系统改造还是全新系统的架构都能游刃有余. 开发者在刚开始尝试实现自己的微服务架构时,往往会产生一系列问题 :.

深度解析DDD中台和微服务设计

- - DockOne.io
随着业务发展,领域模型和微服务会不断变化和演进,如何用最小代价来适应因为业务变化,而带来的领域模型和微服务演进. 建立 DDD、中台和微服务的统一语言. 我们先简单回顾一下中台的发展历程,2017 年《企业 IT 架构转型之道:阿里巴巴中台战略思想和架构实战》出版后,中台就受到业界热捧. 中台的出现是为了解决以往烟囱式和单体架构的重复开发、数据分散和试错成本高的问题,也是为了提高企业市场响应能力,解决巨型企业由于产品种类繁多、部门林立和沟通困难,而导致的商业模式创新难的问题.

DDD CQRS 架构和传统架构的优缺点比较 - .net技术精选 - 开发者头条

- -
最近几年,在DDD的领域,我们经常会看到CQRS架构的概念. 我个人也写了一个ENode框架,专门用来实现这个架构. CQRS架构本身的思想其实非常简单,就是读写分离. 就像我们用MySQL数据库的主备,数据写到主,然后查询从备来查,主备数据的同步由MySQL数据库自己负责,这是一种数据库层面的读写分离.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

面向服务与微服务架构

- - CSDN博客推荐文章
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务,和我最近几年工作的实践比较相关感觉深受启发. 本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过.

微服务架构实践感悟

- - mindwind
从去年初开始接触微服务架构的一些理念,然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念. 最近关于微服务架构的讨论还是多起来,因为国外一些著名互联网公司(如:Amazon、Netflix 等)从实践中摸索出了一套新的大型系统架构方法论,并取得了成功,树立了很好的示范,然后这套方法论渐渐就被一些技术理论派 人士命名为微服务架构(Microservices).

微服务架构成功之路

- - CSDN博客推荐文章
本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/07/success-of-microservices. 近年来,在软件开发领域关于微服务的讨论呈现出火爆的局面,有人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发;同时,反对之声也很强烈,持反对观点的人表示微服务增加了系统维护、部署的难度,导致一些功能模块或代码无法复用,同时微服务允许使用不同的语言和框架来开发各个系统模块,这又会增加系统集成与测试的难度,而且随着系统规模的日渐增长,微服务在一定程度上也会导致系统变得越来越复杂.