前言 哈喽大家好,DDD领域驱动设计系列又开始了,前天周二的那篇入门文章中,也收到了一定的效果(写小说的除外),同时我也是倍感鸭梨,怎么说呢,DDD领域驱动设计已经有十年历史了,甚至更久,但是包括我在内的一批技术人员还是对其不是很明白,这几天我也是日思夜想,怎样才能说的明白,怎样才能把这个高高在上的思想落在实践上,可惜的是国内栗子比较少,国外文章比较少,只能硬啃了,所以更需要大家一起来讨论,这里要说一下,是一起讨论推动,而不是内心去拒绝,而一直和多层架构做对比,这样不仅不利于学习,也无法带动我的…

缘起 哈喽大家周四好,时间是过的真快,这几天一直忙着在公司的项目,然后带带新人,眼看这周要过去了,还是要抽出时间学习学习,这些天看到群里的小伙伴也都在忙着新学习,还是很开心的,至少当时的初衷已经达到了,一起学习一起进步嘛,哪怕是对现在或者是对以后的工作有一丢丢的帮助,也是不枉此时的努力,哈哈夜里写文章总是容易多想,好啦,废话不多说,上次咱们说到了<从壹开始微服务 [ DDD ] 之七 ║项目第一次实现 & CQRS初探>,今天本来应该接着写 领域命令 了,在设计的领域命令的时候,发现了…

前言 哈喽大家周二好,上次咱们说到了实体与值对象的简单知识,相信大家也是稍微有些了解,其实实体咱们平时用的很多了,基本可以和数据库表进行联系,只不过值对象可能不是很熟悉,值对象简单来说就是在DDD领域驱动设计中,为了更好的展示领域模型之间的关系,制定的一个对象,它没有状态和标识,目的就是为了表示一个值.今天呢本来不想说聚合了,因为网上的资料已经铺天盖地,想着开始说领域服务和领域事件了,但是为了本系列的完整性,今天就简单的说一下聚合和聚合根的理解,,如果你已经很明白了,请指出我说的不足之处,以便可…

前言 哈喽大家周五好,我们又见面了,感谢大家在这个周五读我的文章,经过了三周的时间,当然每周两篇的速度的情况下,咱们简单说了下DDD领域驱动设计的第一部分,主要包括了,<项目入门DDD架构浅析>,<领域.子领域.限界上下文>,<DDD使用意义>,<实体与值对象>,<聚合与聚合根>这五部分内容,主要的是以解释为主,举例子Code为辅的形式,总体来说还是得到一些肯定的,也是我最大的动力了. 上边这五个知识点是DDD领域驱动设计的第一部分 —— D领域…

回首 哈喽~大家好,时间过的真快,关于DDD领域驱动设计的讲解基本就差不多了,本来想着周四再开一篇,感觉没有太多的内容了,剩下的一个就是验证的问题,就和之前的JWT很类似,就不打开一个章节了,而且这个也不是领域驱动设计范畴之内的,下一个系列 Ids 的讲解中,可能会穿插着讲一讲,然后到时候正好一起完善了. 虽然是完结了,不过心里还是不是很开森呀,通过小伙伴的反馈,然后我也咨询了官方的建议,好像这个DDD领域驱动设计系列,并没有得到很多的支持,影响力完全比不过第一个系列<从壹开始前后端分离>,原…

缘起 哈喽大家好,又是周二了,时间很快,我的第二个系列DDD领域驱动设计讲解已经接近尾声了,除了今天的时间驱动EDA(也有可能是两篇),然后就是下一篇的事件回溯,就剩下最后的权限验证了,然后就完结了,这两个月我也是一直在自学,然后再想栗子,个人感觉收获还是很大的,比如DDD领域分层设计.CQRS读写分离.CommandBus命令总线.EDA事件驱动.四色原理等等,如果大家真的能踏踏实实的看完,或者说多看看书,对个人的思想提高有很大的帮助,这里要说两点,可能会有一些小伙伴不开心,但是还是要说说:…

缘起 哈喽小伙伴周三好,老张又来啦,DDD领域驱动设计的第二个D也快说完了,下一个系列我也在考虑之中,是 Id4 还是 Dockers 还没有想好,甚至昨天我还想,下一步是不是可以写一个简单的Angular 入门教程,本来是想来个前后端分离的教学视频的,简单试了试,发现自己的声音不好听,真心不好听那种,就作罢了,我看博客园有一个大神在 Bilibili 上有一个视频,具体地址忘了,有需要的留言,我找找.不过最近年底了比较累了,目前已经写了15万字了(一百天,平均一天1500字),或者看看是不是给…

烽烟 哈喽大家周二好呀,咱们又见面了,上周末掐指一算,距离 圣诞节 只有 5 周的时间了(如果你还不知道为啥我要提圣诞节这个时间点,可以看看我的第二系列开篇<之一 ║ D3模式设计初探 与 我的计划书>),然后我简单的思考了下这个DDD领域驱动设计还剩下的知识点,现在已经进入了第二部分,就是领域命令和领域驱动这一块,第三部分包括Identity验证和.net core api等设计点,大概就是剩了这么多,预计应该能在圣诞节前完成.还有一个就是,之前的八篇文章,已经比较完整的实现了普通框架的整体…

缘起 哈喽大家周四好!又是开心的一天,时间过的真快,我们的 <从壹开始 .net core 2.1 + vue 2.5>前后端分离系列共 34 篇已经完结了,当然以后肯定还会有更新和修改,直接在文章内更新,并在文章开头做提醒,如果有大的改动或者新功能,会在目录页进行重点说明(可能简书的更新速度没有博客园快,如果有任何疑问,可以先看博客园的文章,就是上边的这个地址…

烽火 哈喽大家好,老张又见面了,这两天被各个平台的“鸡汤贴”差点乱了心神,博客园如此,简书亦如此,还好群里小伙伴及时提醒,路还很长,这些小事儿就随风而去吧,这周本不打算更了,但是被群里小伙伴“催稿”了,至少也是对我的一个肯定吧,又开始熬夜中,请@初久小伙伴留言,我不知道你的地址,就不放链接了. 收住,言归正传,上次咱们说到了领域命令验证<九 ║从军事故事中,明白领域命令验证(上)>,也介绍了其中的两个角色——领域命令模型和命令验证,这些都是属于领域层的概念,当然这里的内容是 命令 ,查询就当然…

前言 哈喽大家好,今天是周二,我们的DDD系列文章今天正式开始讲解,我这两天一直在学习,也一直在思考如何才能把这一个系列给合理的传递给大家,并且达到学习的目的,还没有特别好的路线,只是一个大概的模糊的安排,毕竟我没有做过讲师,但是我感觉还是需要对自己负责,至少要对得起这个熬夜写的博客吧…

缘起 哈喽大家好哟,今天又到了老张的周二四放送时间了,当然中间还有不定期的更新(因为个人看papi酱看多了),这个主要是针对小伙伴提出的问题和优秀解决方案而写的,经过上周两篇DDD领域驱动设计的试水,我发现一个问题,这个DDD的水是真的深啊~或者来说就是这个思想的转变是不舒服的,好多小伙伴就说有点儿转不过来,当然我也是,一直站在原地追着影子跑,当然这个系列我会一直坚持下去的,大家如果感觉我写的没有误人子弟或者感觉看着还有点儿意思,请不要着急,多多评论,我虽然没有更新,但是也一直在线,提出来的问题…

前言 哈喽,老张是周四放松又开始了,这些天的工作真的是繁重,三个项目同时启动,没办法,只能在深夜写文章了,现在时间的周四凌晨,白天上班已经没有时间开始写文章了,希望看到文章的小伙伴,能给个辛苦赞…

前有幸拜读过诸多大神关于DDD的实现落地等文章,学习较多,受益匪浅,在此推荐 : https://www.cnblogs.com/hafiz/p/9388334.htmlhttps://blog.csdn.net/k6T9Q8XKs6iIkZPPIFq/article/details/78909897https://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.htmlhttps://blog.csdn.net/bluishglc/art…

这是一个基本的微服务+DDD演示例子: 基于 Spring Boot 1.5.6 , Spring Cloud Edgware.SR4 Version 微服务 + DDD,个人觉得应该是首先是从微服务的角度(如何划分微服务)考虑去划分大的业务模块,每一个微服务都应该是一个可以单独部署,各司其职的模块: 微服务实际开发中,也结合DDD的思想去划分所有属于自己的领域. 微服务的划分与落地,其实也应该是以DDD的思想做去指导的,所以无论我们代码结构如何规划,也并非一成不变,应该从实际出发,去思考划分结…

微服务架构,一个当下比较火的概念了.以前也只是了解过这方面的概念,没有尝试过.想找找.NET生态下面是否有现成的实现,可是没找到,就花了大半个月的闲暇时间,遵循着易用和简单,实现了一个微服务框架,我叫它Stardust(星尘),Stardust有三个项目组成: Stardust.Server是服务端组件,Stardust.Client是客户端组件,Stardust.ConfigCenterWeb是配置中心,是个MVC web站点. 本文目录: 基础模型和组件 服务节点与配置中心 客户端与配置中心…

一.了解微服务架构 1.微服务技术栈 整体框架 整体学习规划路线2.微服务与单体架构的区别 单体架构:将业务的所有功能集中在一个项目中开发,打成一个包部署 优势 结构简单 部署成本低 缺点 耦合度高,不利于构建和开发 3.分布式架构:根据业务功能对系统进行拆分,每个业务模块作为独立项目开发,成为一个服务. 优点: 降低服务耦合度 有利于服务升级扩展 缺点: 架构非常复杂 运维.监控,部署难度提高 4.微服务:是一种经过良好架构设计的分布式架构方案 微服务架构特征: 单一职责:微服务菜饭粒度更小,…

安装 npm install m-service --save 使用 编写服务处理函数 // dir1/file1.js // 使用传入的console参数输出可以自动在日志里带上request id,便于跟踪一个请求在所有微服务上的日志 // 返回值如果是非null,则会把该值JSON.stringify后作为结果返回,若是promise,则等待promise的结果再返回 module.exports.f1 = (console, query, body, req, res)=>{ retur…

在整个微服务体系中,除了注册中心具有非常重要的意义之外,还有一个注册中心.注册中心作为管理在整个项目群的配置文件及动态参数的重要载体服务.Spring Cloud体系的子项目中,Spring Cloud Config子项目就是该注册中心.在整个分布式框架系统中,充当重要角色. 官方解释 Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed sys…

1. 引言 限界上下文可以拆分为两个词,限界和上下文. 限界:是指一个界限,具体的某一个范围. 上下文:个人理解就是语境. 比如我们常说的段子: "我想静静." 这个句子一般是想表达"我想静一静"的意思.但是我们却把它玩笑成"静静是谁?". 可见上下文语境很重要. 这个例子只是个开胃菜,我们接着往下看. 2. 案例分析 整个应用程序之内的一个概念性边界. 边界之内的每种领域术语.词组或句子--也即通用语言,都有确定的上下文含义. 边界之外,这些术…

RPC调用是面向服务架构场景下进行服务间调用的常用组件,一个完整的RPC调用的流程如图1所示: 图1 RPC调用流程 为了方便RPC调用者和服务者的开发,开发者们开发了很多RPC框架.比较有名的RPC框架有Google的gRPC.Facebook的Thrift 和 阿里的 Dubbo 等.这些框架在具体实现上虽然各不相同,但其工作原理基本上是一致的. 一个设计良好的RPC框架的愿景是简化服务提供者和调用者的开发,将图1中 2~8 步骤的所有操作全部隐藏,让开发者可以像开发和调用本地方法一样开发和…

作者:薇文文链接:https://www.jianshu.com/p/20ed82218163来源:简书 准备工作 先安装Protobuf 编译器 protoc,下载地址:https://github.com/google/protobuf/releases 我的是windows,将压缩包bin目录下的exe放到环境PATH目录中即可. 然后获取插件支持库 // gRPC运行时接口编解码支持库 go get -u github.com/golang/protobuf/proto // 从 Pro…

一.Springboot增加Prometheus 1.Spring Boot 应用暴露监控指标,添加如下依赖 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <dependency> <groupId>io.pr…

你是否还在为微服务应该拆多小而争论不休?到底如何才能设计出收放自如的微服务?怎样才能保证业务领域模型与代码模型的一致性?或许本文能帮你找到答案. 本文是基于 DDD 的微服务设计和开发实战篇,通过借鉴领域驱动设计思想,指导微服务项目团队进行设计和开发(理论篇详见<当中台遇上 DDD,我们该如何设计微服务?>).本文包括三部分内容:第一部分讲述领域驱动设计基本知识,包括:分层架构.服务视图.数据视图和领域事件发布和订阅等:第二部分讲述微服务设计方法.过程.模板.代码目录.设计原则等内容:最后部分…

你是否还在为微服务应该拆多小而争论不休?到底如何才能设计出收放自如的微服务?怎样才能保证业务领域模型与代码模型的一致性?或许本文能帮你找到答案. 本文是基于 DDD 的微服务设计和开发实战篇,通过借鉴领域驱动设计思想,指导微服务项目团队进行设计和开发(理论篇详见<当中台遇上 DDD,我们该如何设计微服务?>).本文包括三部分内容:第一部分讲述领域驱动设计基本知识,包括:分层架构.服务视图.数据视图和领域事件发布和订阅等:第二部分讲述微服务设计方法.过程.模板.代码目录.设计原则等内容:最后部分…

小结: 1. 微服务中台不是 /1堆砌技术组件就是中台 /2拥有服务治理就是中台 /3增加部分业务功能就是中台 /4Cloud Native 就是中台 https://mp.weixin.qq.com/s/uuaraAWReOYeZuEJiLs9dw 企业微服务中台落地实践和思想之我见 From  朱德明 InfoQ 4/3 微服务和中台是这几年非常时髦随处可见的词,最先在一批互联网企业中开始谈论和建设,并逐渐的蔓延至一些传统企业和传统的 IT 部门,以至于现在在构建信息系统时,很多企业都在说要…

一.微服务的注册与发现——Eureka 和许多分布式设计一样,分布式的应用一般都会有一个服务中心,用于记录各个机器的信息.微服务架构也一样,我们把一个大的应用解耦成这么多个那么多个服务,那么在想要调用这些服务的时候要怎么办呢? 这个时候就需要我们的Eureka了,它是用来发现和注册各个微服务的,简单理解这个东西的作用就是,告诉你现在有哪些微服务,他们的IP啊端口什么的,然后告诉你怎么去调用他们. 下面的图简单的描述了大致的过程: Spring Cloud提供了多种注册中心的支持:如Eureka.…

本文来自作者 未闻 在 GitChat 分享的{基于 Docker 的微服务架构实践} 前言 基于 Docker 的容器技术是在2015年的时候开始接触的,两年多的时间,作为一名 Docker 的 DevOps,也见证了 Docker 的技术体系的快速发展.本文主要是结合在公司搭建的微服务架构的实践过程,做一个简单的总结.希望给在创业初期探索如何布局服务架构体系的 DevOps,或者想初步了解企业级架构的同学们一些参考. Microservice 和 Docker 对于创业公司的技术布局,很多声…

1.消息通信 传统的单体应用,组件间的调用都是使用代码级的方法函数.比如用户登录自动签到,增加积分.我们可以在登录函数调用积分模块的某个函数,为了解耦我们使用以来注入并放弃new Class()这种方式.但是不管哪种方式都是在同一个进程里. 讲一个单体应用改为微服务应用的最大挑战就是改变通信机制,直接把进程内方法调用改成服务间的 RPC 调用会导致在分布式环境中性能低下的.零散的和低效的通信. 通信类型 异步还是同步的:• 同步协议. HTTP 是一种同步协议.客户端发起一个请求然后等待服务端响…

SOA体系架构 面向服务的体系结构 (SOA) ,通过将应用程序分解为多个服务(通常为 HTTP 服务,WCF服务等),将其分为不同类型(例如子系统或层),从而来划分应用程序的结构. 微服务源自 SOA,但 SOA 不同于微服务体系结构. 诸如大型中央代理.组织级别的中央业务流程协调程序和企业服务总线 (ESB) 等功能在 SOA 中很典型. 但在大多数情况下,这些是微服务社区中的反模式. 微服务架构 微服务体系结构是一种将服务器应用程序生成为一组小型服务的方法. 每个服务都在自己的进程中运行,…