红色有角F叔对《领域驱动设计》的笔记(11)

红色有角F叔
红色有角F叔 (次元の呪い)

读过 领域驱动设计

领域驱动设计
  • 书名: 领域驱动设计
  • 作者: 埃文斯
  • 副标题: 软件核心复杂性应对之道
  • 页数: 369
  • 出版社: 人民邮电出版社
  • 出版年: 2010-11
  • 知识丰富的设计
    当我们的建模不再局限于寻找实体和值对象时,我们才能充分吸取知识,因为业务规则之间可能会存在不一致。领域专家在反复研究所有规则、解决规则之间的矛盾以及常识来弥补规则的不足等一系列工作中,往往不会意识到她们的思考过程有多么复杂。
    2016-11-09 10:07:27 回应
  • 文档和图
    尽管存在所有这些细节,但属性和关系只是对象模型的一部分。这些对象的行为以及这些对象上的约束就不那么容易表示了。对象交互图可以阐明设计中的一些复杂之处,但却无法用这种方式来展示大量的交互,就是工作量太大了,既要制作图,还要学习这些图而且交互图也只能暗示出模型的目的。要想把约束和断言包括进来,需要在 UML 中使用文本。
    操作名称可能会暗示出对象的行为职责,对象交互图中也会隐含地展示出这些职责,但无法直接表述。
    如果确实能使用 UML 这样的绘图语言来编写可执行程序,那么 UML 图就会退化为程序本身的另一种视图,这样,“模型” 的真正含义就丢失了。
    图是一种沟通和解释手段,它们可以促进头脑风暴。简洁的小图能够很好地实现这些目标,而涵盖整个对象模型的综合性大图反而失去了沟通或解释能力
    设计的重要细节应该在代码中体现出来。良好的实现应该是透明的,清楚地展示其背后的模型。
    2016-11-14 22:12:42 回应
  • “大声地”建模
    改善模型的最佳方式之一就是通过对话来研究,试着大声说出可能的模型变化中的各种结构。这样不完善的地方很容易被听出来。
    事实上,我们的大脑似乎很擅长处理口语的复杂性。例如,当具有不同语言背景的人凑在一起做生意时,如果没有公共语言,他们就会创造一种称为“混杂语”的公共语言。混杂语虽然不想讲话者的母语那样详尽,但它适合当前任务。
    2016-11-14 22:37:22 回应
  • 关联
    尽可能地对关系进行约束是非常重要的。双向关联意味着只有将这两个对象放在一起考虑才能理解它们。当应用程序不要求双向遍历时,可以指定一个遍历方向,以便减少相互依赖,并简化设计。
    2016-11-21 22:50:31 回应
  • 粒度
    由于应用层负责对领域对象的行为进行协调,因此细粒度的领域对象可能会把领域层的知识泄露到应用层中。这产生的结果是应用层不得不处理复杂的、细致的交互,从而使领域知识蔓延到应用层或用户界面代码中,而领域层会丢失这些知识。
    2016-11-21 23:18:31 回应
  • 模式:Service
    所谓 Service,它强调的是与其他对象的关系。与 Entity 与 Value Object 不同,它只是定义了能够为客户做什么,Service 往往是以一个活动来命名,而不是以一个 Entity 来命名。
    好的 Service 有以下三个特征: - 与领域概念相关的操作不是 Entity 或 Value Object 的一个自然组成部分。 - 接口是根据领域模型的其他元素定义的。 - 操作是无状态的。
    2016-11-22 20:58:47 回应
  • 模式: Module
    分层架构可能导致模型对象实现的分裂。
    当使用 J2EE 早期版本时,一种常见的做法是把数据和数据访问放到“实体bean”中,而把相关的业务逻辑放到“会话bean”中。这样做除了导致每个组件的实现变得更复杂以外,还破坏了对象模型的内聚性。
    有时,方面的分离也是有帮助的,具体来讲,把持久化代码移出来可以减少很多混乱。
    但最重要的是,这个项目的框架要求将每个层放到单独的一组包中,并根据层的标识惯例来命名。这一下子就把我们所有的注意力都吸引到分层上来。
    这种框架设计是再尝试解决两个合理的问题。一个问题是关注点的逻辑划分:一个对象负责数据库访问,另外一个对象负责处理业务逻辑,等等。这种划分方法是人们更容易(在技术层面上)理解每个层的功能,而且更容易切换各个层。这种设计的问题在于没有顾及应用程序的开发成本。
    这些打包方案的另一个动机是层的分布。如果代码实际上被部署到不同的服务器上,那么这会成为这种分层的有力论据。但通常并不是这样,应该在需要时才寻求灵活性。
    除非真正有必要讲代码分布到不同的服务器上,否则就把实现单一概念对象的所有代码放在同一个模块中。
    2016-11-22 21:13:01 回应
  • 深层模型/柔性设计
    如果每次对模型和代码所进行的修改都能反映出对领域的新理解,那么通过不断的重构就能给系统最需要修改的地方增添灵活性,并找到简单快捷的方式来实现普通的功能。戴久了的手套在手指关节处会变得柔软;而其他部分则依然硬实,可起到保护的作用。
    深层模型使设计更具表现力;同时,当设计的灵活性可以让开发人员进行试验,而设计又能清晰地表达出领域含义时,那么这个设计实际上就能够将开发人员的深层理解反馈到整个模型发现的过程中。
    2016-11-22 22:38:42 回应
  • 选择重构目标
    当你遇到一个杂乱无章的大系统时,应该从哪里入手呢?在 XP 社区中,答案往往是以下之一: 1. 可以从任何地方开始,因为所有的东西都要重构; 2. 从影响你工作的那部分开始——也就是完成具体任务所需要的那个部分; 这两种做法我都不赞成。第一种做法并不可行,只有少数完全由顶尖的程序员组成的团队才是例外。第二种做法往往只是对外围问题进行了处理,只治标而不治本,回避了最严重的问题。最终这会使得代码变得越来越难以重构。 因此,如果你既不能全面解决问题,又不能“哪儿痛治哪儿”,那么该怎么办呢? 1. 如果采用“哪儿痛治哪儿”这种重构策略,要观察一下根源问题是否涉及 core domain 或 core 的支持元素的关系。如果确实涉及,那么就要接受挑战,首先修复核心。 2. 当可以自由选择重构的部分时,应首先集中精力把 core domain 更好地提取出来,完善对 core 的分离,并且把支持性德子领域提炼成通用子领域。 以上就是如何从重构中获取最大利益的方法。
    2016-12-04 14:10:16 1人喜欢 回应
  • 模式:Generic Subdomain
    识别出那些与项目意图无关的内聚子领域。把这些子领域的通用模型提取出来,并放到单独的 Module 中。任何专有的东西都不应放在这些模块中。 把它们分离出来以后,在继续开发的过程中,它们的优先级低于 core domain 的优先级,并且不要分派核心开发人员来完成这些任务(因为他们很少能够从这些任务中获取领域知识)。此外,还可以考虑为这些 Generic Subdomain 使用现成的解决方案或者“公开发布的模型”(Published Model)。
    比如账户认证这类。
    2016-12-04 14:13:51 回应
<前页 1 2 后页>

红色有角F叔的其他笔记  · · · · · ·  ( 全部654条 )

注定一战
1
美国反对美国
1
哲学·科学·常识
1
计算机组成(第6版)
2
图解TCP/IP(第5版)
1
沸腾十五年
2
重新理解创业
8
雄性衰落
3
股市真规则
1
资本和收入的性质
2
存在主义是一种人道主义
3
程序员的职业素养
1
何为良好生活
1
活出生命的意义
3
货币的教训
3
Docker——容器与容器云(第2版)
2
政治的人生
4
中国巨债
3
深入浅出React和Redux
5
历史的教训
4
聪明的投资者
8
Designing Data-Intensive Applications
4
投资中最简单的事
5
供给的逻辑
1
逃不开的经济周期
1
图解服务器端网络架构
1
斯坦福极简经济学
3
政治的逻辑
4
原则
5
大数据之路
1
在苍茫中传灯
4
巴菲特传(纪念版)
1
中产阶级如何保护自己的财富
1
指数基金投资指南
4
模式分类
2
深度学习
1
我看电商
2
数据挖掘导论
1
中国国家治理的制度逻辑
2
漫步华尔街
2
尽在双11:阿里巴巴技术演进与超越
2
共同基金常识
3
企业IT架构转型之道:阿里巴巴中台战略思想与架构实战
6
未来简史
2
MySQL DBA修炼之道
1
大国大城
2
计算广告
4
机器学习
1
集体智慧编程
1
重新定义公司
1
Hadoop应用架构
1
第二性
6
硅谷钢铁侠
1
大数据
5
经营的本质
1
人人都是产品经理
7
你凭什么做好互联网
4
Spark机器学习
2
聊聊架构
8
游戏引擎架构
1
美国大城市的死与生(纪念版)
5
给大家看的Photoshop讲座
1
技术的本质
5
我们房地产这些年
2
行动的勇气
2
合作的进化
5
马克斯·韦伯与德国政治:1890—1920
6
数据库索引设计与优化
1
精益企业
7
高可用MySQL
2
发布!软件的设计与部署
2
项目管理艺术
2
右派国家
5
现实感
4
从0到1
1
高效程序员的45个习惯
1
可扩展的艺术
3
空之境界 上
1
成为技术领导者
1
改革的逻辑
3
修改代码的艺术
9
恰如其分的软件架构
7
软件开发者路线图
3
实现领域驱动设计
1
21世纪资本论
9
持续交付
16
构建之法
6
黑格尔导论
19
极端的年代
1
微服务设计
10
Site Reliability Engineering
5
测试驱动的面向对象软件开发
3
城市的胜利
2
对知识的恐惧
5
ZeroMQ
6
现代经济学主要流派
7
数学之美
2
程序员的思维修炼
1
大教堂与集市
1
一切坚固的东西都烟消云散了
5
兜售繁荣
1
数据科学与工程技术丛书
1
政治的细节(第10版)
8
发展研究指南(第二版)
2
代码大全(第2版)
2
企业应用架构模式
9
The Datacenter as a Computer
3
无情的革命
6
新教伦理与资本主义精神
3
人类简史
7
Understanding MySQL Internals
2
他改变了中国
1
态度改变与社会影响
4
复杂
2
民主新论
19
人件
2
国家的常识
4
乌合之众
3
Web Operations
2
个人印象
4
湖上闲思录
2
自由及其背叛
7
C++语言的设计与演化
8
百年中国经济史笔记
1
改变
4
创新与企业家精神
5
Cassandra
3
不敢止步
4
意志力
2
通向财务自由之路
1
制造同意
6
美国种族简史
4
NoSQL Distilled
4
理解专业程序员
2
一个自由主义者的良知
4
政治经济学要义
2
施瓦辛格健身全书
2
房地产的繁荣与萧条
5
为学十六法
2
Akka in Action
1
Java虚拟机并发编程
3
软件工艺
3
面向模式的软件架构,卷3
1
动物精神
4
非理性繁荣
10
MongoDB权威指南
2
海量数据库解决方案
1
Erlang/OTP并发编程实战
1
学术与政治
12
Java并发编程实战
16
论中国
3
金融炼金术
4
多处理器编程的艺术
1
Effective java 中文版(第2版)
1
中國近代史(下冊)
6
系统之美
6
压力下的角逐
2
古代东方史
1
Go 语言程序设计
1
Remote
1
深入Linux内核架构
2
中國近代史(上冊)
3
隐秩序
1
空之境界(上下集合售)
1
开放社会
4
中国近代史八种
5
喀提林阴谋 朱古达战争
1
政治秩序的起源
5
现代性的后果
2
失去的胜利
9
了不起的盖茨比
5
许倬云说历史:台湾四百年
2
大规模分布式存储系统
1
C++网络编程(卷1)
2
在约定的场所
1
中国的宗教
2
了不起的盖茨比
1
希腊罗马名人传(全三册)
2
自私的基因
2
学龠
1
中国政治思想史
4
列克星敦的幽灵
1
人月神话
2
现代体系结构上的UNIX系统
1
虚拟机
2
朱熹的历史世界
1