领域模型

Python面向对象编程——领域模型 领域建模 。 从领域模型开始,我们就开始了面向对象的分析和设计过程,可以说,领域模型是完成从需求分析到面向 对象设计的一座桥梁。 领域模型,顾名思义,就是需求所涉及的领域的一个建模,更通俗的讲法是业务模型。 参考百度百科( http://baike.baidu.cn/view/757895.htm ),领域模型定义如下: 从这个定义我们可以看出,领域模型有两个主要的作用: 1、发掘重要的业务领域模型。 2、建立业务领域概念之间的关系。 领域建模三字经 领域模型如此重要,很多同学可能会认为领域建模很复杂,需要很高的技巧。然而事实上领域建模非常简 单,简单得有点难以让人相信,领域建模的方法概括一下就是“ 找名词 ”! 许多同学看到这个方法后估计都会笑出来:太假了吧,这么简单,找个初中生都会啊,那我们公司那些分析师和设计师还有什么用哦? 分析师和设计师当然有用,后面我们会看到,即使是简单的找名词这样的操作,也涉及到分析和提炼,而 不是简单的摘取出来就可,这种情况下分析师和设计师的经验和技能就能够派上用场了。但领域模型分析 也确实相对简单,即使没有丰富的经验和高超的技巧,至少也能完成一个能用的领域模型。 虽然我们说“找名词”很简单,但一个关键的问题还没有说明: 从哪里找 ? 如果你还记得领域模型是“需求到面向对象的桥梁”,那么你肯定一下子就能想到

一、前言 　 　在前面专题一中，我已经介绍了我写这系列文章的初衷了。由于dax.net中的DDD框架和Byteart Retail案例并没有对其形成过程做一步步分析，而是把整个DDD的实现案例展现给我们，这对于一些刚刚接触领域驱动设计的朋友可能会非常迷茫，从而觉得领域驱动设计很难，很复杂，因为学习中要消化一个整个案例的知识，这样未免很多人消化不了就打退堂鼓，就不继续研究下去了，所以这样也不利于DDD的推广。然而本系列可以说是刚接触领域驱动设计朋友的福音，本系列将结合领域驱动设计的思想来一步步构建一个网上书店，从而让大家学习DDD不再枯燥和可以看到一个DDD案例的形成历程。最后，再DDD案例完成之后，将从中抽取一个领域驱动的框架，从而大家也可以看到一个DDD框架的形成历程，这样就不至于一下子消化一整个框架和案例的知识，而是一步步消化。接下来，该专题将介绍的是：结合领域驱动设计的SOA架构来构建网上书店，本专题中并没有完成网上书店的所有页面和覆盖DDD中的所有内容，而只是一部分，后面的专题将会在本专题的网上书店进行一步步完善，通过一步步引入DDD的内容和重构来完成整个项目。 二、DDD分层架构 　　 从概念上说，领域驱动设计架构主要分为四层，分别为：基础设施层、领域层、应用层和表现层。 基础结构层：该层专为其他各层提供各项通用技术框架支持。像一些配置文件处理、缓存处理

说起应用分层，大部分人都会认为这个不是很简单嘛 就 Controller ， Service , Mapper 三层。看起来简单，很多人其实并没有把他们职责划分开，在很多代码中, Controller 做的逻辑比 Service 还多, Service 往往当成透传了，这其实是很多人开发代码都没有注意到的地方，反正功能也能用，至于放哪无所谓呗。这样往往造成后面代码无法复用，层级关系混乱，对后续代码的维护非常麻烦。 一、背景 一个好的应用分层需要具备以下几点: 方便后续代码进行维护扩展； 分层的效果需要让整个团队都接受； 各个层职责边界清晰。 二、如何进行分层 2.1、阿里规范 在阿里的编码规范中约束的分层如下: 开放接口层：可直接封装 Service 方法暴露成 RPC 接口;通过 Web 封装成 http 接口;进行 网关安全控制、流量控制等。 终端显示层：各个端的模板渲染并执行显示的层。 Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。 Service 层：相对具体的业务逻辑服务层。 Manager 层：通用业务处理层，它有如下特征: 对第三方平台封装的层，预处理返回结果及转化异常信息; 对 Service 层通用能力的下沉，如缓存方案、中间件通用处理; 与 DAO 层交互，对多个 DAO 的组合复用。 DAO 层：数据访问层，与底层

多视图的方法不仅仅是架构归档技术，更是指导我们进行架构设计的思维方法。 越是复杂的系统，越是需要从多个方面进行架构设计，这样才能把问题研究和表达清楚，而提供不同的软件架构视图也便于交流和传递设计思想。 关键需求是对软件架构设计起关键作用的需求子集，包括功能需求、质量需求和商业需求三种，架构细化必须注意满足这些需求。 领域模型是以面向对象方式对问题领域的模型的模拟和抽象，它揭示了重要的业务领域概念，并建立业务领域概念之间的关系，领域模型被不断精化后成为最终软件系统的问题领域层，它决定了软件系统的功能范围，并影响着软件系统的可扩展性。 概念性架构是对系统设计的最初构想，通过主要的设计元素及它们之间的关系来描述系统，这些高层次的设计选择对未来软件系统的质量和功能都有关键作用。 约束可以视为一类特殊的需求，它们具有强制性，规定了业务和技术上的标准和限制。 我们利用架构视图的方法，从逻辑架构、开发架构、运行架构、物理架构和数据架构五个方面来进行架构设计。 设计逻辑架构：使用 UML 来描述，静态方面包括包图、类图、对象图；动态方面包括序列图、协作图、状态图和活动图。 逻辑架构的设计应该完成的工作： 细化功能单元 发现通用机制 细化领域模型 确定子系统接口和交互机制 因为软件架构的重点在于‘软件系统的各部分是如何相关的’，那么我们可以经过适度的抽象分析，将几组协作中的公共行为提取出来成为

回到目录 概念中的ＤＤＤ ＤＤＤ：　领域驱动设计，它是对面向对象的的分析和设计（ＯＯＡＤ，Object Orient Analysis Design）的一个补充，对技术框架进行了分层规划，同时对每个类进行了策略和类型划分。领域模型是领域驱动的核心　，采用ＤＤＤ的设计思想，业务逻辑不再集中在几个大型的类上，而是在大量相对小的领域对象上，这些类具有自己的状态和行为，每个类都是完成的独立的，并与现实领域的业务对象形成一种映射。基于ＤＤＤ的架构设计，保证了系统的可维护性，扩展性和敏捷性，在处理复杂业务逻辑方面有着明显的优势！ 编程世界观的改变 以下信息是从http://www.jdon.com/ddd.html上拷贝的，写的很好，这确实是一种编程世界观的改变，而传传统编程观念完全不同 过去需求分析和系统设计都是分离的，正如我们国家“系统分析师” 和“系统设计师” 两种职称考试一样，这样割裂的结果导致，需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却 扭曲需求 ，导致客户运行软件后才发现很多功能 不是自己想要的 ，而且软件 不能快速跟随需求变化 。 　　DDD则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。 　　DDD革命性在于：领域模型准确反映了业务语言，而传统的分层架构只关心数据， 这些数据对象除了简单读、写操作外

注：科比今天要退役了，我是 60 亿分之一，满腹怀念～😭😭😭 前几天看了园友的一篇文章《 我眼中的领域驱动设计 》，文中有段话直击痛点： 有人误认为项目架构中加入 Repository，Domain，ValueObject 就变成了 DDD 架构 。没错，我就是这样，不过准确的来说，并不能称为 DDD 架构，而是我之前经常说的“ 伪 DDD ”设计，后来我还抽离出了一个伪 DDD 设计框架： DDD.Sample ，大家有兴趣的可以瞧瞧，在实际项目的开发中，我用它做过了几个不太大的项目，我个人觉得用起来很顺手，当然并没有真正的 DDD 设计，只不过用了一个空的架构而已，然后冠以”DDD 开发“的名号。 因为之前有过 DDD 设计的痛苦经历（短消息系统），具体表现就是，如果真正 DDD 设计，需要花费大量的时间和精力，可能几天都在思考一个问题或者考虑几行代码的编写，但最后也可能没什么结论或结果，并且这个过程是很艰难和痛苦的，所以我后来就变懒了，懒的去思考项目所表现的业务，也不再考虑如何去设计领域模型，只是在考虑如何让框架用起来更爽，DDD.Sample 前两个应用的实际项目，我都是在完善这个框架，比如 Repository 和 UnitOfWork 的设计等等，所以，关于领域模型的设计，就是一堆贫血模型。不过，后来应用的第三个项目，也就是上一个实际项目，我觉得不能再这样下去了

DDD（Domain Driven Design 领域驱动设计）本质上是管理和维护软件复杂性的一种方法，设计作为软件工程领域不可或缺的一个环节，其本身是重要的，但并不是全部，要想做出真正能用的产品，软件工程领域的其他要素都是不可或缺的。 在领域设计之初，要牢记"软件作为一个产品，其优雅来源于系统简约的设计；软件实现的过程本身是一个工程过程，它的的完整依赖于工程理论及工艺流程的完整"。与其他全部设计方式一样，DDD仅仅是一种可行的手段，软件及其工程的本质，依然是对软件自身概念完整性的把握以及在流程中每一个环节上的一丝不苟。 在这里谨慎的提醒那些对于软件及工程的某些侧面倍加推崇的人们，在软件开发领域从没出现过万能的良药，即使某些技术或领域曾经倍受推崇，甚至短暂的大放异彩，但到目前为止，还没有任何单一的手段能够彻底的解决软件开发领域的根本问题，这是由软件的本质与人的素质之间的根本矛盾决定的，多年前，我看到《人月神话》中关于这一问题的探究，一直在反复验证，至今依然没有发现反例，姑且将此作为软件工程领域的第一定律，写在开篇之初，用以时时自省。 领域是在计算世界中基于自然属性的一种提炼和抽象，是现实世界的另一种表达方式。领域模型是现实世界在计算领域的完整映射而不是一个抽象简化或残缺的版本, 领域是完整的,所以由领域对象构成的系统自然也应当是完整的。 在抽象到计算世界的领域模型中

框架已经完成，开始设计了 1、根据业务流程，分析领域模型。尽量客观的描述一些功能主体，这些主体应该有哪些功能，具体这些功能由谁使用暂时可以不是很严谨的表述。比如门店能干啥、而不是门店的员工在干啥 业务流程的分析，其实就是功能模块的划分和完善 2、限界上下文，限的意思就是划分、规定，界就是界限、或者一个边界，上下文就是业务的整个流程。 3、一整套系统就是一个限界上下文，下边清理其子域：核心域、支撑子域和通用子域。其中核心域、子域也可以表达为一个子领域模型，这样一层层嵌套下去。限界上下文定义了领域模型的边界。 核心域 领域模型的主要业务因素，是解决此领域问题主要建模部分。 子域 对该核心域的提供支撑的关联域 或 系统通用部分的功能支持。 通过子域划分和对领域概念的深入发掘，有助于创建现实世界的更合理抽象。分别思考和实现两个较小规模的系统，要比实现一个大规模的系统容易的多。更细粒度的划分也增加了复用的机会和对业务演进的更好支持。 细化模型时候，并反复迭代，确认模型是否满足需求，限界上下文的设计是否合理，是否有利于复用和扩展。 7-24 多租户 SaaS是Software-as-a-Service（软件即服务）的简称，随着互联网技术的发展和应用软件的成熟， 在21世纪开始兴起的一种完全创新的软件应用模式。它与“on-demand software”（按需软件)，the

一、什么是业务领域建模 领域建模： 从领域模型开始,我们就开始了面向对象的分析和设计过程,可以说,领域模型是完成从需求分析到面向对象设计的一座桥梁。 顾名思义,就是显示最重要的业务概念和它们之间关系，是真实世界各个事物的表示（现实世界的可视化抽象字典）而不是软件中各构件的表示。领域模型是描述业务领域（业务实体）的静态结构。 理论派观点： Domain Model是一个商业建模范畴概念，即使一个企业不开发软件，也具备其业务模型；所有同行企业，其业务模型必定有非常大的共性和内在的规律性。 由行业内的各个企业的业务模型再向上抽象出整个行业的业务模型，这个模型称之为“领域模型”。 领域模型是一种特殊的业务模型，它分析范围是整个行业，抽象出行业里共性和内在规律性的业务，比业务模型更加抽象，它不属于软件开发范畴的概念，与软件开发无关。 实战派观点： 领域模型是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。 是需求分析人员与用户交流的有力工具，是彼此交流的语言。 领域模型是一种分析模型，在软件开发过程分析阶段用于分析如何满足系统功能性需求，属于软件开发范畴，在UML中主要使用类图来描述领域模型。 业务模型是业务建模的输出物，业务建模研究的对象是公司或者组织，业务建模属于软件开发过程中的初始阶段。

一.领域建模Domain Modeling定义 领域模型(domain model)是对领域内的概念类或现实世界中对象的可视化表示。领域模型也成为概念模型、领域对象模型和分析对象模型。 二.业务领域建模原因 领域建模可以降低软件和现实世界之间的差异，用真实的业务概念划分职责，目的是实现一个可以高效低成本维护的可持续发展的软件系统。 从领域模型推导到系统实现是一套引导思考的方式，也是一套科学的开发流程。其核心目的在于提供了系统设计的“指导方针”。领域模型必须站在用户需求和业务发展的角度上，既可以用来同客户沟通验证需求，又可以避免模型因实现的考量而带偏（实现成本、遗留系统） 软件工程师需要在不同的领域或不同的项目中工作，来自不同的背景，这可能会影响他们对应用程序域的感知。他们需要领域知识来开发系统。 三.模型(Model)通常由2部分组成： 1. 对象（Object） 2.对象间的关系(Relationship) 四. 领域建模（Domain Modeling）/业务分析的主要就是： 1.寻找业务对象（Business Object） 2.恰当建立这些对象间的关系 3.添加关联和属性 五.领域模型设计的步骤（如何进行领域建模）： 5.1用例分析法 用例分析法是进行领域建模最简单可行的方式。其步骤如下： 1.获取用例描述 既然我们的领域模型指的是问题域模型，那么建模也一定要从问题域入手