《领域驱动设计 软件核心复杂性应对之道》 - 书摘精要

(序)

领域模型的最大价值是它提供了一种通用语言,这种语言是将领域专家和技术人员联系在一起的纽带;

(P2)

模型是一种知识形式,他对知识进行有选择的简化和有目的的结构化;

(P33)

面向对象编程之所以功能强大,是因为它基于建模范式,并且为模型构造提供了实现方式;

(P48)

领域驱动设计只有应用在大型项目上才能产生最大的收益,而这也确实需要高超的技巧;

(P70)

在大型系统中,中等粒度的、无状态的 Service 更容易被重用,因为它们在一个简单的接口背后封装了重要的功能;

细粒度的对象可能导致分布式系统中的消息传递的效率低下;

(P91)

应该将创建复杂对象的实例和聚合的职责转移给一个单独的对象,这个对象本身在领域模型中可能没有职责,但它仍是领域设计的一部分;

(P128)

《重构》一书中所列出的重构分类涵盖了大部分常用的微重构;

(P131)

持续重构是在为突破做好准备;

(P302)

尽管任何一次突破都会得到一个有价值的深层模型,但只有 Core Domain 中的突破才能改变整个项目的轨道;

(P346)

检验软件成功与否的最有效的方法是让它运行一段时间;

时间: 2024-10-29 19:10:23

《领域驱动设计 软件核心复杂性应对之道》 - 书摘精要的相关文章

《领域驱动设计与模式实践》 - 书摘精要

(P5) 技术性的东西变化不定,唯有核心业务才是持久的.当核心业务改变时,模型和软件必须随之改变: (P9) .Net 更好地支持面向对象,它只是更好的工具箱: 把技术看作是助推器,不同的技术可能是比其他技术更好的助推器: (P10) 性能问题常常是由于糟糕的数据库存取代码.数据库结构或其他类似原因造成的: (P12) 事情并不总是一成不变的,要考虑背景: (P13) 除非确实需要优化,否则一定不要提前优化: (P21) 发明框架是很麻烦的,更好的想法是直接获取框架: (P22) 思维比工具重要

书籍推荐:领域驱动设计与模式实战

我们在平时的学习中或多或少的接触到一些领域驱动设计(Domain-Driven Design,DDD)这些概念,这些概念也非常抽象,最重要的在国内也没有这方面的优秀书籍或者指导手册.也没有一些典型的Sample提供我们学习DDD. 在DDD领域中,就属Eric Evans大师的"Domain-Driven Design: Tackling Complexity in the Heart of Software"和Jimmy Nilsson大师的"Applying Domain

EntityFramework之领域驱动设计实践

EntityFramework之领域驱动设计实践 - 前言 EntityFramework之领域驱动设计实践 (一):从DataTable到EntityObject EntityFramework之领域驱动设计实践 (二):分层架构 EntityFramework之领域驱动设计实践 (三):案例:一个简易的销售系统 EntityFramework之领域驱动设计实践 (四):存储过程 - 领域驱动的反模式 EntityFramework之领域驱动设计实践 (五):聚合 EntityFramewor

(转)EntityFramework之领域驱动设计实践

EntityFramework之领域驱动设计实践 - 前言 EntityFramework之领域驱动设计实践 (一):从DataTable到EntityObject EntityFramework之领域驱动设计实践 (二):分层架构 EntityFramework之领域驱动设计实践 (三):案例:一个简易的销售系统 EntityFramework之领域驱动设计实践 (四):存储过程 - 领域驱动的反模式 EntityFramework之领域驱动设计实践 (五):聚合 EntityFramewor

我眼中的领域驱动设计

有幸参与了一些领域驱动的项目,读了一些文章,也见识了一些不伦不类的架构,感觉对领域驱动有了更进一步的认识.所以今天跟大伙探讨一下领域驱动设计,同时也对一些想要实践领域驱动设计却又无处下手,或者一些正在实践却又说不上领域驱动设计到底好在哪的朋友一些建议.当然对于领域驱动设计这个主题而言从来不乏争论,所以大家可以在畅所欲言. 为什么要使用领域驱动设计? 从Eric Evans写的<领域驱动设计:软件核心复杂性应对之道>一书的书名就可以看出这一方法论是为了解决软件核心复杂性的.也就是说软件业务越来越

如何运用领域驱动设计 - 聚合

原文:如何运用领域驱动设计 - 聚合 目录 概述 何为聚合 演化案例 发现实体关系 开始划分边界吧 选取一个聚合根 通过聚合根保护你的内部对象 聚合的一些特性 通过ID引用 聚合真的是不变的吗 小的聚合 一致性 总结 概述 在前几篇的博文中,我们已经学习到了如何运用实体和值对象.随着我们所在领域的不断深入,领域模型变得逐渐清晰,我们已经建立了足够丰富的实体和值对象.但随着实体和值对象的数量逐渐增多,它们之间的关系也显得越来越复杂:实体A与实体B存在一对一的关系,实体B又与实体C存在一对多的关系.

如何运用领域驱动设计 - 值对象

原文:如何运用领域驱动设计 - 值对象 目录 概述 何为值对象 值对象是基于上下文的 当前上下文的值对象可能是另一个上下文的实体 怎么运用值对象 尽量避免使用基元类型 值对象是内聚并且可以具有行为 来看一个例子 值对象的持久化 总结 概述 作为领域驱动设计战术模式中最为核心的一个部分-值对象.一直是被大多数愿意尝试或者正在使用DDD的开发者提及最多的概念之一.但是在学习过程中,大家会因为受到传统开发模式的影响,往往很难去运用值对象这一概念,以及在对值对象进行持久化时感到非常的迷惑.本篇文章会从值

如何运用领域驱动设计 - 领域服务

原文:如何运用领域驱动设计 - 领域服务 目录 概述 什么是领域服务 从实际场景下手 更贴近现实 领域服务VS应用服务 扩展上面的需求 最常见的认证授权是领域服务吗 使用领域服务 不要过多的使用领域服务 不要将过多的行为都给了领域服务 总结 小彩蛋 概述 本文将介绍领域驱动设计(DDD)战术模式中另一个非常重要的概念 - 领域服务.在前面两篇博文中,我们已经学习到了什么是值对象和实体,并且能够比较清晰的定位它们自身的行为.但是在某些时候,你会发现某一些业务行为好像不容易落到单个实体或者值对象身上

.NET领域驱动设计—初尝(一:疑问、模式、原则、工具、过程、框架、实践)

.NET领域驱动设计—初尝(一:疑问.模式.原则.工具.过程.框架.实践) 2013-04-07 17:35:27 标签:.NET DDD 驱动设计 原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 .作者信息和本声明.否则将追究法律责任.http://wangqingpei557.blog.51cto.com/1009349/1173006 1.1.疑问 1.1.1.UML何用 1.1.2.领域建模 1.2.模式 1.3.原则 1.4.工具 1.5.过程 1.6.框架 1.7.项