问题:
1、 何为领域驱动设计(DOMAINDriven DESIGN)/p>
2、 UBIQUITOUS LANGUAGE(领域通用语言)应该是如何去描述
3、
第二部分 模型驱动设计的构造块
第四章 分离模型
分层架构如图:
模式:Aggregate
每个对象模型都应该找到它的聚合根,其他仅对该模型有效的应通过聚合根来得到而不应该直接访问该对象
隔离领域:应用程序的引入
三个用户层的应用程序功能:
1、 第一个类时TrackingQuery(跟踪查询)
2、 第二个类是BookingApplication(预定应用)
3、 第三个类是IncidentLoggin Application(事件日志应用)
设计运输系统中的关联
第三部分通过重构来加深理解
深层模型能够穿过领域表象,清楚地表达出领域专家们的主要关注点以及最相关的知识。
第8章突破
第九章 将隐式概念转变为显示概念
倾听领域专家使用的语言。有没有一些术语能够简洁地表达出复杂的概念们有没有纠正过你的用词你使用某个特定短语时,他们脸上还流露出迷惑的表情吗些都暗示了某个概念也许可以改进模型。
模式:Specification
第十章 柔性设计
模式:Intention-Revealing Interfaces
一些有助于获得柔性设计的模式

在命名类和操作时要描述他们的效果和目的,而不要表露它们是通过何种方式达到目的的。这样可以使客户开发人员不必去理解内部的细节。这些名称应该与Ubiquitous language保持一致,以便团队成员可以迅速推断出它们的意义。在创建一个行为之前先为它编写一个测试,这样可以促使你站在客户开发人员的角度上来思考它。
模式:Side Effect Free Function
尽可能把程序的逻辑放到函数中,因为函数是只返回结果而不产生明显副作用的操作。严格地把命令(引起明显的状态改变的方法)隔离到不返回领域信息的,非常简单的操作中。当发现了一个非常合适承担复杂逻辑职责的概念时,就可以把这个复杂逻辑移到Value Object 中,这样可以进一步控制副作用。
模式:Assertion
把操作的后置条件和类及Aggregate的固定规则表述清楚。如果在你的编程语言中不能直接编写Assertion,那么就把他们编写成自动的单元测试。还可以把他们写到文档或图中。
寻找在概念上内聚的模型,以便使开发人员更容易退出预期的Assertion,从而加快学习过程并避免代码矛盾。
模式:Conceptual contour
把设计元素(操作、接口、类和Aggregate)分解为内聚的单元,在这个过程中,你对领域中一切重要划分的直观认识也要考虑在内。在连续的重构过程中观察发生变化和保证稳定的规律性,并寻找能够解释这些变化模式的底层Conceptual contour。使模型与领域中那些一致的方面(正是这些方面使得领域成为一个有用的知识体系)相匹配。
模式:Standalone Class
在对象设计时保持低耦合是一个基本要素。把其他所有无关概念提取到对象之外。这样类就变成完全孤立的了,这就使得我们可以单独地研究和理解它。每个这样的孤立类都极大的减轻了因理解Module而带来的负担。
模式:Closure of operation
在适当的情况下,在定义操作时让它返回类型与其参数的类型相同。如果实现者的状态在计算中会被用到,那么实现者实际上就是操作的一个参数,因此参数和返回值应该与实现者有相同的类型。这样的操作就是在该类型的实例集合中的闭合操作。闭合操作提供了一个高层接口,同时又不会引入对其他感念的任何依赖性。
第十一章 分析模式的应用
第十二章 将设计模式应用与模型
模式:Strategy(也称为Policy)
我们需要把过程中的易变部分提取到模型的一个单独的“策略”对象中。将规则与它所控制的行为区分开。按照strategy设计模式来实现规则或可替换的过程。策略对象的多个版本表示了完成过程的不同方式。
模式:ComPosite
定义一个把composite的所有成员都包含在内的抽象类型,在容器上实现一些用来查询信息的方法,这些方法可用来收集与容器内容有关的信息。“叶”节点基于它们自己的值来实现这些方法,客户只需使用抽象类型,而无需区分“叶”和容器。
第十三章 通过重构得到更深层的理解
第十四章 保存模型的完整性
模式:Bounded Context
明确地定义模型所应用的上下文。根据团队的组织、软件形同的各个部分的用法以及物理表现(代码和数据库模式等)来设计模型的边界。在这些边界中严格模型的一致性,而不要受到边界以外问题的干扰和混淆。
模式:Continuous integration
建立一个经常把所有代码和其他实现2工件合并到一起的过程,并通过自动测试来快速查明模型的分裂问题。严格坚持使用Ubiquitous Language,以便在不同人的头脑中演变出不同的概念时,使所有者对模型都能达成一个共识。
模式:Context Map
识别每个模型在项目中的作用,并定义其Bounded Context。这包括非面向对象子系统的隐含模型。为每个BoundedContext命名,并把名称添加到Ubiquitous language中。
描述模型之间的接触点,明确每次交流所需的转换,并突出任何共享的内容。
从领域模型中选出两个团队都同意共享的一个子集。当然,除了模型的这个子集以外,这还包括与该模型部分相关的代码子集,或数据库设计的子集。这部分明确共享的内容具有特殊的状态,而且一个团队在没与另一个团队商量的情况下不应该擅自更改它。
模式:Customer/Supplier Development team
在两个团队之间建立一种明确的客户/供应商关系。在计划会议中,下游团队相当于上游团队的客户。根据下游团队的需求来协商需要执行的任务并为这些任务做预算,以便每个人都知道双方的约定和进度
模式:Conformist
通过严格遵从上游团队的模型,可以消除在Bounded context之间进行转换的复杂性。尽管这会限制下游设计人员的风格,而且可能不会得到理想的应用程序模型,但选择conformity模式可以极大的简化集成。此外,这样还可以与供应商团队共享一种ubiquitous language。供应商处于驾驶者的位置上,引擎最好使他们能够容易沟通。他们从利他主义的角度出发,会与你分享信息。
模式:Anticorruption layer
创建一个隔离层,以便根据客户资金的领域模型来为客户提供相关的功能。这个层通过其现有接口与另一个系统进行对话,而只需对那个系统做出很少的修改,甚至无需修改。在内部,这个层在两个模型直接进行必要的双向转换。
模型:Open host service
定义一个协议,把你的子系统作为一组service供其他系统访问。开放这个协议,以便所有需要与你的子系统集成的人都可以使用它。当有新的集成需求时,就增强并扩展这个协议,但个别团队的特殊需求除外。满足这种特殊需求的方法是使用一次性的转换器来扩充协议,以便使公事协议简单并内聚。
模式:Published language
把一个良好文档化、能够表达出所需领域信息的共享语言作为公共的通信媒介,必要时在其他的信息与该语言之间进行转换。
第十五章 精炼
模式:core domain
对模型进行提炼。找到Core domain 并提供一种易于区分的方法把它与那些辅助作用的模型和代码分开。最有价值和最专业的概念要轮廓分明。尽量压缩Core DOMAIN。
模式:Generic SubDomain
把内聚的子领域(他们不是项目的动机)识别出来。把这些子领域的通用模型提取出来,并放到单独的MODULE中。任何专有的东西都不应放到这些模块中。
模型:Domain vision statement
写一份Core domain的简短描述以及它将会创造的价值,也就是“价值主张”。那些不能讲你的领域模型与其他领域模型区分来的方面就不要写。展示出领域模型是如何实现和均衡各方利益的。这份描述要尽量精简。
模型:Highlighted core
模型:Cohesive mechanism
把概念上的Cohesive Mechanism(内聚机制)分离到一个单独的轻量级框架中。要特别注意公司算法或那些有完备文档的算法。用一个Intention revealing interface来公开这个框架的功能。现在,领域中的其他元素就可以只专注与如何表达问题(做什么)了,而把解决方案的复杂细节(如何做)转移给了框架。
模式:Segregated core
对模型进行重构,把核心概念从支持性元素(包括定义得不清楚的那些元素)中分离出来,并增强Core的内聚性,同时减少它与其他代码的耦合。把所有通用元素或支持性元素提取到其他对象中,并把这些对象放到其他的包中-即使这会把一些紧密耦合的元素分开。
模式:Abstract core
把模型中最基本的概念识别出来,并分离到不同的类、抽象类或接口中。设计这个抽象模型,使之能够表达出重要组件之间的大部分交互。把这个完整的抽象模型放到它自己的module中,而专用的、详细的实现类则留在由子领域定义的Module中。
第十六章 大比例结构
大比例结构什么意思
模式:Evolving order
模式:system metaphor
模式:responsibility layer
模式:Knowledge level
模式:Pluggable component framework
文章知识点与官方知识档案匹配,可进一步学习相关知识Python入门技能树人工智能机器学习工具包Scikit-learn212682 人正在系统学习中 相关资源:c#编写的鸡兔同笼程序
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!