ddd

DDD峰会归来话DDD

荒凉一梦 提交于 2019-11-27 11:02:57
一场大戏落幕,首届DDD中国峰会如大会主题色一般的红。或许在12月9日这一天,全中国的DDD粉丝大约有一半都汇聚在了国家会议中心。听起来是幸,其实是不幸,因为DDD在中国的人群基数实在是太少了。 因为要负责大会的其中一个Track,期间又要接受采访,另外还有朋友到访,所以除了前面的两个keynote以及我自己的session(这是当然的),我没有完整听完一个session。然而单单是和DDD大咖、专家与爱好者们交谈,已经受益匪浅了。参会归来,关于DDD的idea产生了许多,我觉得有必要和DDD谈谈我的想法。 DDD是什么 正如Alberto在keynote中提到,DDD不是架构。我赞同这一观点,并一直认为DDD是一种方法论(Methodology)。根据维基百科:Methodology is the systematic, theoretical analysis of the methods applied to a field of study,DDD正是针对软件领域提供的系统与理论分析方法。Eric在创造性地提出DDD时,实则是针对当时项目中聚焦在Data(主要是DB Schema)为核心的系统建模方法的批判。这种面向数据的建模方式无法应对日渐复杂的业务逻辑,也无法更好地应用当时正沸沸扬扬的OO设计思想。这是 设计观念的转变,蕴含了全新的设计思想、设计原则与设计过程 。

从DDD开始说起

…衆ロ難τιáo~ 提交于 2019-11-27 04:16:12
前言 从13年接触DDD之后开始做应用架构已经整整四个年头. 四年里关于DDD的感触良多,慢慢有了一些心得. 关于DDD的介绍已经有很多的文章和书籍,这里我推荐三本最重要的书籍. 《领域驱动设计-软件核心复杂性应对之道》(DDD) 《实现领域驱动设计》(IDDD) 《领域驱动设计模式,原理与实践》(PPPDDD) 具体的DDD介绍这三本书已经很清楚了,但是学完这些之后我认为DDD才刚刚开始. DDD给我更多的是一种设计启发,无论是里面的战术设计,还是战略设计都可以展开到很多点. 书籍里面很多时候只是一些设计原则,和一些简单的demo,但是基于这些原则作为出发点,可以展开很多的设计. 架构有时候就是一个生长的,当我基于DDD为起点,不断演进架构.这时候架构仿佛也有了生命力,不断地成长,到最后可能是最开始完全想想不到的样子,我想这大概就是架构的魅力.但是无论如何,DDD都是一个起点. 下面是我总结的基于DDD发散的一些知识体系 下面会有简单的描述 仓储 DDD中仓储将持久化这个技术复杂性保持在领域模型之外. 具体来说有以下在具体实践中有以下几点: 1.隔离领域模型和数据模型:衍生出来就是隔离内存里面的模型和持久化模型.这个点会在EAV的设计中体现的淋漓尽致. 2.技术复杂度的封装:仓储负责如何组织模型存储. 静态分库:按照领域上下文(或者模块)分库,所谓纵向分库

轻松学DDD之一:模型驱动设计

孤街浪徒 提交于 2019-11-26 02:57:52
轻松学DDD之一:模型驱动设计   我是2012年开始接触到DDD(领域驱动设计)的, 后续陆陆续续研读过几遍Eric的大作《领域驱动设计:软件核心复杂性应对之道》,也使用DDD重构过一个项目。总的感受是DDD的一些概念比较晦涩难懂,很难掌握,因此想写个系列短文,希望能用通俗易懂的语言帮助大家更轻松更深入地理解DDD。文章很多都是我个人体会和理解,难免有错误,希望大家能及时指正,共同提高。   本文是系列短文第一篇,介绍DDD的起始概念 模型驱动设计 。 1. 软件开发方法回顾   软件开发可以看做是一个把用户需求转换为可正确运行的程序的过程,其中最关键部分是把用户需求转换成代码。我们要学习的DDD实际上就是一种软件开发方法,它相比之前的软件开发方法,能更好地应对软件的核心复杂度。为了能更好的理解它,我们先回顾下之前的软件开发方法及其存在问题。   在上世纪60年代,由于需求简单,软件开发以作坊式开发为主。但是随着硬件的飞速发展,软件复杂度也迅速激增,终于在70年引发了软件危机。为了应对危机,业界借鉴成熟生产制造管理方法,发展出以“过程为中心”的瀑布式开发方法。 1.1 瀑布式开发   瀑布式开发把整个软件开发过程划分为需求分析、方案设计、编码、测试等阶段,希望以这种类似工业流水线的作业分工方式来控制软件开发的风险和成本。 需求分析 :通过需求分析我们需要明确用户想要的功能

轻松学DDD之二:如何高效消化知识

依然范特西╮ 提交于 2019-11-26 01:55:40
轻松学DDD之二:如何高效消化知识   我是2012年开始接触DDD的,后续研读过几遍《领域驱动设计:软件核心复杂性应对之道》,也用DDD做过项目。总的感受是DDD的一些概念比较晦涩难懂,很难掌握,因此想写个系列短文,希望能帮助大家更轻松地理解DDD。文章很多都是我个人体会和理解,难免有错误,希望大家能及时指正,共同探讨提高。前面短文链接:    轻松学DDD之一:模型驱动设计   本文是系列短文第二篇,介绍 如何高效消化知识 。      1. 知识来源 在讲如何消化知识前,我们要明确下建模的知识来源有哪些。首先我们通过下图来考察模型、领域、软件、现实世界、计算机系统等几个概念的关联。 现实世界(蓝线左半边)和计算机系统(蓝线右半边)。 我们把用户需求理解为用户要求我们构建一个特定的计算机系统,通过它用户能按自己的期望来改变现实世界。比如淘宝网就是一个这样的计算机系统,通过它阿里巴巴可以让商品销售变得更快捷、更方便、成本更低。 领域和软件。 领域就是用户需求和从用户需求这个视角出发对现实世界的认知集合;软件就是可以让计算机系统按照用户期望方式来运转的程序。 领域模型。 它富含领域知识,与实现绑定,能够把领域和软件有效地耦合起来,从而能够让我们基于模型快速开发功能丰富的软件产品。 从上面的认知我们可以知道 模型就是在用户目标和软件实现技术的约束下对领域知识的精确化、结构化和抽象。

ddd

拜拜、爱过 提交于 2019-11-25 21:21:42
<!DOCTYPE html> < html> < head> < meta charset= "UTF-8 "> < title>Insert title here</ title> </ head> < body> < script> window. location. href = "https://www.cnblogs.com/jxnc/ " </ script> </ body> </ html> 来源: https://www.cnblogs.com/jxnc/p/11930213.html