摘要 mvc是一种软件设计模式,最早由Trygve Reenskaug在1978年提出,他有效的解决了表示层,控制器层,逻辑层的代码混合在一起的问题,很好的做到了职责分离.但是在实际的编码实践过程中,你会发现这个模式随着业务的扩展,变的逻辑混乱,代码重合度很高.这里提出借鉴DDD思想的一种新的工程结构 mvc的问题 通常一个前后端分离的系统,后端工程系统结构图通常下面这样 1. 四层 controller/service/manager/mapper 2. 不可以同级调用 3. 上级可以知晓下级…
摘要 在前面一篇介绍了如何通过DDD的思想,来调整单体服务内的工程结构,为微服务的拆分做准备.同时介绍了我们在进行微服务拆分的时候踩过的一些坑. 这篇介绍下我们最终的方案,不一定对,欢迎留言讨论. 微服务划分 问题分析 上篇介绍过我们一开始的服务划分标准 一个领域一个服务的规则去拆分, 同时为了保证领域的纯洁性,我们区分了领域服务,和前台服务.领域服务就是领域逻辑,不直接对前端暴露.前台服务组装各个领域服务,暴露给前端. 同时为了保持扩展,我们预留了一个微服务作为服务孵化器.对于领域不清晰的(比…
摘要 前面两篇介绍了DDD的目标管理.DDD的工程结构调整.这篇讨论微服务的划分.微服务是目前后端比较流行的架构体系了,那么如何做好一个微服务的划分?一个微服务的粒度应该是多大呢?这篇主要介绍如何结合DDD进行领域划分. 工程结构代码 上篇介绍了可落地的DDD的(2)-为什么说MVC工程架构已经过时 很多朋友留言说,有没有sample code,要不然太湿了,不是很明白.这里写了个sample. 就以一个博客网站为例 page1:博客列表页: 展示所有用户发表的博客 page2: 个人介绍页:有…
摘要 本篇是DDD的战术篇,也就是关于领域事件.领域对象.聚合根.实体.值对象的讨论.也是DDD系列的完结篇. 这一部分在我们团队争论最多的,也有很多月经贴,比如对资源库的操作应该放在领域服务还是领域对象中. 聚合根应不应该暴露给外部,还是要转成DTO.这些问题我们讨论了大半年,最后大家基本达成了共识,在当前的业务规模下, 这些问题没那么重要,可东可西.不会对代码的质量有啥大的影响.关于DDD的实践,与团队的水平.业务复杂度息息相关.我们的经验并不一定就适用你们团队.我将战术篇的这么多的内容放在…
背景 几年前我总结过DDD战术设计的一些落地经验可落地的DDD(5)-战术设计,和一次关于聚合根的激烈讨论最近两年有些新的落地体验,回过头来发现,当初对这些概念的理解还是没有深入,这篇文章重新阐述下. 之前理解不到位的点有 战术设计的各个模块是的协作关系 哪些是问题空间问题,哪些是方案空间问题边界没有划分清楚. 实体和聚合根的区别理解不不深刻,实体和聚合根建模的方法不对. 以上问题将会在下文解释清楚. 战术设计拆解 DDD的战术设计即设计某个子域的领域模型以及代码落地.领域事件.领域对象.聚合根…
目录 前言 一.从六边形架构谈起 二.依赖倒置 三.DDD 代码分层 3.1 用户接口层 3.2 应用层 3.2 1 Response vs Exception 3.2.2 CQE vs DTO 3.2.3 Anti-Corruption Layer防腐层 3.3 领域层 3.4 基础设施层 参考资料 前言 网上那么多DDD的文章,但代码工程却没有一个比较好的例子,本文将手把手跟你一起写DDD代码,学习DDD思想与代码相结合带来的好处. 一.从六边形架构谈起 六边形架构也称端口与适配器.对于每种…
领域驱动设计的概念 ​ 大家都知道软件开发不是一蹴而就的事情,我们不可能在不了解产品(或行业领域)的前提下进行软件开发,在开发前通常需要进行大量的业务知识梳理,然后才能到软件设计的层面,最后才是开发.而在业务知识梳理的过程中,必然会形成某个领域知识,根据领域知识来一步步驱动软件设计,就是领域驱动设计(DDD,Domain-Driven Design)的基本概念 . 为什么需要 DDD ​ 在业务初期,功能大都非常简单,普通的 CRUD 就基本能满足要求,此时系统是清晰的.但随着产品的不断迭代和演…
阅读目录: 1.开篇介绍 2.简单了解缘由(本文的前期事宜) 3.DomainModel扩展性(运用设计模式设计模型变化点) 3.1.模型扩展性 3.2.设计模式的使用(苦心专研的设计模式.设计思想可以随意使用了) 3.3.部分类的使用(封装内部对象) 3.4.高强度的OO设计(面向特定领域的高度抽象设计形成特定领域框架) 4.DomainModel业务逻辑规则配置(将扩展点分离后使用适当的配置将规则IOC进去) 5.DDD简单总结(DDD是什么?它是“战术”) 1]开篇介绍 这篇文章不会太长,…
阅读目录: 1.开篇介绍 2.简单了解缘由(本文的前期事宜) 3.DomainModel扩展性(运用设计模式设计模型变化点) 3.1.模型扩展性 3.2.设计模式的使用(苦心专研的设计模式.设计思想可以随意使用了) 3.3.部分类的使用(封装内部对象) 3.4.高强度的OO设计(面向特定领域的高度抽象设计形成特定领域框架) 4.DomainModel业务逻辑规则配置(将扩展点分离后使用适当的配置将规则IOC进去) 5.DDD简单总结(DDD是什么?它是“战术”) 1]开篇介绍 这篇文章不会太长,…
前言 基于 DDD 传统分层架构实现. 项目 github地址:https://github.com/WuMortal/DDDSample 这个分层架构是工作中项目正在使用的分层架构,使用了一段时间发现受益匪浅,所以整理好我对该分层架构的一些理解分享给大家,我对于该分层架构还处于学习阶段理解有误的地方请指出.本次会以一个案例来说明各个分层的作用以及他们之间的调用关系,还有本次的重点不在于DDD,因为这个我还未能完全理解,当然避免不了中间会涉及DDD的一些概念. DDD 简单介绍 DDD 什么?为…
摘要 在之前的文章DDD-CQRS能解什么问题中,阐述了什么是CQRS.但是并没有业务需求可以应用CQRS.最近需要处理一个文本增量更新的业务,经过需求分析后,尝试使用CQRS来解这个问题 问题分析 一个文本页面编辑,对象很大,之前是全量保存.涉及到的网络传输对象比较大,经常超时OOM,所以交互改成,只保存修改的部分,也就是增量更新. 之前业务中没法使用CQRS,在于使用CQRS后,数据的维护变得异常麻烦.比如我对一个表单进行了反复修改,生成了N份历史修改数据,获取最新数据时需要对这些历史数据进…
小结: 1. 微服务中台不是 /1堆砌技术组件就是中台 /2拥有服务治理就是中台 /3增加部分业务功能就是中台 /4Cloud Native 就是中台 https://mp.weixin.qq.com/s/uuaraAWReOYeZuEJiLs9dw 企业微服务中台落地实践和思想之我见 From  朱德明 InfoQ 4/3 微服务和中台是这几年非常时髦随处可见的词,最先在一批互联网企业中开始谈论和建设,并逐渐的蔓延至一些传统企业和传统的 IT 部门,以至于现在在构建信息系统时,很多企业都在说要…
从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故障.所以,我们希望通过各种措施提高服务的质量和稳定性.其中的一个措施就是希望能做一个灰度发布的平台,这个…
原文地址:http://www.cnblogs.com/netfocus/p/5548025.html 从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故…
DDD领域驱动设计的理解 从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故障.所以,我们希望通过各种措施提高服务的质量和稳定性.其中的一个措施就是希望能…
本系列所有文章 如何一步一步用DDD设计一个电商网站(一)—— 先理解核心概念 如何一步一步用DDD设计一个电商网站(二)—— 项目架构 如何一步一步用DDD设计一个电商网站(三)—— 初涉核心域 如何一步一步用DDD设计一个电商网站(四)—— 把商品卖给用户 如何一步一步用DDD设计一个电商网站(五)—— 停下脚步,重新出发 如何一步一步用DDD设计一个电商网站(六)—— 给购物车加点料,集成售价上下文 如何一步一步用DDD设计一个电商网站(七)—— 实现售价上下文 如何一步一步用DDD设计一…
概述 DDD为复杂软件的设计提供了指导思想,其将易发生变化的业务核心域放置在限定上下文中,在确保核心域一致性和内聚性的基础上,DDD可以被多种语言和多种技术框架实现,具体的框架实现需要根据实际的业务场景和需求来制定. 核心的指导思路归纳为: 关注点放在domain上,将业务领域限定在同一上下文中 降低上下文之间的依赖,通过‘开发主机服务’(REST服务是其中的一种).‘消息模式’.‘事件驱动’等架构风格实现 遵循分层架构模式 架构风格 针对DDD的架构设计,<实现领域驱动设计>提到了几种架构风…
领域驱动设计(DDD:Domain-Driven Design) Eric Evans的"Domain-Driven Design领域驱动设计"简称DDD,Evans DDD是一套综合软件系统分析和设计的面向对象建模方法,提出了领域模型概念,统一了分析和设计编程,使得软件能够更灵活快速跟随需求变化. 回顾历史: 服务器后端发展的三个阶段 UI+DataBase 最原始的两层架构,这种面向数据库的架构完全没有灵活性! UI+Service+DataBase 多层SOA架构, 这种服务+表…
从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故障.所以,我们希望通过各种措施提高服务的质量和稳定性.其中的一个措施就是希望能做一个灰度发布的平台,这个…
何为DDD DDD不是架构设计方法,不能把每个设计细节具象化,DDD是一套体系,决定了其开放性,体系中可以用任何一种方法来解决这些问题,但是如果一些关键问题没有具体方案落地,可能让团队无所适从. 有的小伙伴觉得DDD太虚了,具体在我们进行业务代码编写落地中DDD主要解决什么问题呢? 总结起来说主要目的有两点: 建立业务术语,统一PM/RD/QA需求沟通术语. 梳理业务边界,将业务领域逻辑内聚. 搞定DDD要解决的问题 如何进行领域建模 如何识别Bounded Context 如何在战术层面寻找对…
从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故障.所以,我们希望通过各种措施提高服务的质量和稳定性.其中的一个措施就是希望能做一个灰度发布的平台,这个…
DDD.DSL 和 DCI DDD 概念最早提出于 2004 年,作为一种软件开发的指导思想,DDD 对软件开发带来了诸多可能与方向,张晓龙认为 DDD 为软件开发带来的好处主要有以下几点: 首先,最大好处就是所有参与者围绕一个统一一致的领域模型工作,传统的分析模型和设计模型不再割裂,不管是做设计.做分析还是写代码.写文档,脑海中所构建的画面都是一致的. 第二,DDD 是一个软件开发过程,它显式地把领域和设计放到了软件开发的核心,软件人员和业务人员被受到同样的重视,他们合作来构建领域模型,使得软…
可落地的DDD(5)-战术设计   摘要 本篇是DDD的战术篇,也就是关于领域事件.领域对象.聚合根.实体.值对象的讨论.也是DDD系列的完结篇.这一部分在我们团队争论最多的,也有很多月经贴,比如对资源库的操作应该放在领域服务还是领域对象中.聚合根应不应该暴露给外部,还是要转成DTO.这些问题我们讨论了大半年,最后大家基本达成了共识,在当前的业务规模下,这些问题没那么重要,可东可西.不会对代码的质量有啥大的影响.关于DDD的实践,与团队的水平.业务复杂度息息相关.我们的经验并不一定就适用你们团队…
DDD不是架构设计方法 一文读懂DDD 2019-05-28 19:18 by 春哥大魔王, 413 阅读, 3 评论, 收藏, 编辑 何为DDD DDD不是架构设计方法,不能把每个设计细节具象化,DDD是一套体系,决定了其开放性,体系中可以用任何一种方法来解决这些问题,但是如果一些关键问题没有具体方案落地,可能让团队无所适从. 有的小伙伴觉得DDD太虚了,具体在我们进行业务代码编写落地中DDD主要解决什么问题呢? 总结起来说主要目的有两点: 建立业务术语,统一PM/RD/QA需求沟通术语. 梳…
网易新闻App架构重构实践:DDD正走向流行 https://mp.weixin.qq.com/s/FdwrT_xn3CQqpWoRVBttvQ 小智 InfoQ 2020-05-14 作者 | 小智嘉宾 | 李云鹏当前,大多数移动开发团队选择以 MVP 作为业务层的核心架构模型,在此基础上实现了客户端的组件化.插件化.容器化等,但作为业务层核心的 MVP 架构模式至今仍有诸多弊端.网易新闻 App 在领域驱动设计(DDD)思想指导下,对其架构做了整体重构,得到了不错的重构质量与项目收益.移动端…
目录 学好了DDD,你能做什么? 领域驱动设计:微服务设计为什么要选择DDD? 领域.子域.核心域.通用域和支撑域:傻傻分不清? 限界上下文:定义领域边界的利器 实体和值对象:从领域模型的基础单元看系统设计 聚合和聚合根:怎样设计聚合? 领域事件:解耦微服务的关键 DDD分层架构:有效降低层与层之间的依赖 微服务架构模型:几种常见模型的对比和分析 中台:数字转型后到底应该共享什么? DDD.中台和微服务:它们是如何协作的? 学好了DDD,你能做什么? 我认为,要想应用 DDD,首要任务就是要吃透…
作者:小傅哥 博客:https://bugstack.cn 原文:https://mp.weixin.qq.com/s/ezd-6xkRiNfPH1lGwhLd8Q 沉淀.分享.成长,让自己和他人都能有所收获! 一.前言 领导:为什么要使用DDD? 我也苦思冥想,怎么跟领导说咱们从 MVC 升级到 DDD 吧,因为 DDD 代码结构更加清晰.领域驱动比测试驱动开发更加先进.研发的兄弟们也更想用用新框架等. 不过这么聊被喷一顿不说,还得说你是过度设计瞎折腾,咋回事呢?因为没聊到重点呀,你MVC升级…
一.引子 聊架构总离不开"领域驱动架构",大多能聊到DDD(Domain-Driven Design),实际上早期思想EBI架构 1992年就诞生了.核心价值点在于:关注核心业务领域(高内聚),分离实现层(低耦合).后续一些演变架构有:端口和适配器架构.洋葱架构.整洁架构.事件驱动架构.这一系列的架构演变,每个架构的核心思想了解下就好,不用纠结实现细节. 二.架构演变 2.1 EBI 架构(1992) EBI 架构(Entity-Boundary-Interactor,实体-边界-交互…
上一篇:<DDD 领域驱动设计-谈谈 Repository.IUnitOfWork 和 IDbContext 的实践(1)> 阅读目录: 抽离 IRepository 并改造 Repository IUnitOfWork 和 Application Service 的变化 总结三种设计方案 简单总结上篇所做的两个改进: 从 Repository 和 UnitOfWork 中抽离出 IDbContext,并且它们只依赖于 IDbContext. Repository 和 UnitOfWork 为…
引言 自动化金字塔-灵魂手绘版 关于Web自动化测试,投入产出比是一个绕不开的话题,对于走到2017年的测试人,这时候可能已经有很多人会想到著名的自动化测试金字塔.它形象地展示了Mike Cohn对自动化分层中各层所应该投入比重的看法,可以作为我们Web自动化实施策略的重要参考. 我最初开始接触Web自动化测试的时候,没有直接的领路人,测试行业知识也远不及如今这么丰富和易获取,当时我对于自动化测试的分层几乎没有什么了解,更不知道什么金字塔,就如很多同行一样,我一开始先入的是UI自动化的坑,那时候…