常用于做网站的软件,医疗 企业 网站制作,wordpress 知更鸟 网格,新浪微博图床wordpress1 从搬砖谈领域对象有一个古老的故事#xff0c;大概是这样的。作者问三个建筑工地上的工人他们在干什么#xff1f;有一个没精打采的说#xff0c;我在挖洞#xff01;而另一一个人却说#xff0c;我在盖一座房子。还有一个人说#xff0c;我在建立一座巨大的城市。… 1 从搬砖谈领域对象 有一个古老的故事大概是这样的。作者问三个建筑工地上的工人他们在干什么有一个没精打采的说我在挖洞而另一一个人却说我在盖一座房子。还有一个人说我在建立一座巨大的城市。不同的思维模式决定了不同的发展十年过后第一个工人还是在挖洞而第二个则成为了工头。第三个最终却成为了大设计师。 在软件开发领域往往会使用搬砖这个词来形容我们所开发的每个功能模块实际上也确实如此如果把我们需要完成的每个项目比作一座高楼大厦那么在项目中所完成的各种模块也确实是我们在计算机世界中利用砖块设计出来的精美建筑构建。而从领域驱动的角度来说可以把关系类比为建筑工程图纸中使用的各种辅助线也可以把领域驱动中所涉及的各个对象类比成砖块这些砖块大概有两种一种是实体Entity一种是值对象(Value Object)而使用这些对象的工具则成为服务Service)完成的各个建筑构建被成为包或者模块Module).2 关联关系 在介绍领域驱动设计的第三篇文章《领域驱动设计让程序员心中有码三》中笔者提到了UML中常用的几种关系而关联关系是一种最为常见的关系。在软件设计过程中无所不在的关联有时候会让软件工程设计变得更加复杂。因此在设计关联关系时应该让关联更加易于控制这意味着需要采取下列三种措施 1、规定一个遍历方向。对象与对象间过于双向关联是一种低效的关系而指定唯一的遍历方向将有效的减少相互的依赖实现设计的简化。 2、添加一个限定符以便有效地减少多重关联。过于复杂的多对多关系最终形成一个纷繁复杂难以控制的图结构而限定多对多关联的遍历方向可以有效的简化多对多关系为一对多关联。 3、消除不必要的关联。上述两个步骤的目的也正是为了消除对于当前工作或模型对象的基本含义来说不重要的关联。实际上正是为了当前模型对象的简化。3 实体 在软件开发过程中我们通常会定义模型和实体对象这种实体对象同样也是领域驱动中的基本对象。按照大家的理解通常而言实体是指能够与数据库直接映射的对象。在领域驱动设计中使用的则是更加妥当的说法对象具有贯穿整个生命周期甚至会经历多种形式的抽象的连续性。 实体标识任何事物只要满足两个条件即可一个是它在整个生命周期中具有联系性二是他的区别并不是有哪些对用户来说非常重要的属性决定而是通过标识来决定的。 3.1 实体建模 由于实体对象的基本职责是为了确保连续性其行为应该是非常清楚并且可以预测的。因此保持实体的简练是实现责任的关键。应该抓住实体的基本特征而不要一味地过分求全求完美。对于实体而言应该只添加对概念来说至关重要的行为和这些行为所必须的属性。其他行为应当转移到与核心实体关联的其他对象中。实体则通过协调与之关联的其他对象来完成自己的基本职责。3.2 设计实体的标识 在面向对象开发中会使用建立标识这种操作方式来实现与其他对象的区分。哪怕是在分布式系统中同样需要使用标识来确保标识的唯一性。可以使用具有唯一性的属性来提供标识也可以使用ID的方式来实现。这种ID如果使用系统自动生成往往需要有一些手段确保生成的唯一性尤其是在分布式系统中更是一个非常困难的问题。经常使用的方式是使用redis或zookeeper这些中间件来生成唯一标识还有一种常见的方案是使用twitter的Snowflake算法这些算法就不再赘述了。4 值对象 值对象则不具备Entity这种明确的连续性如果在设计系统时将所有的对象都定义为实体对象实际上将会极大的增加系统的复杂度所以需要定义一些用于描述领域的某个方面本身没有概念标识的喜爱那个。例如可以通过邮编对地址进行检索邮编的变更对地址也可能会发生变化那么地址就是具有连续性的实体对象。而在电子商务系统中只需根据地址即可完成投递而无需确保地址的连续性那么他就是值对象了。 值对象往往使用与需要通过一个模型元素的属性来定义模型的场景主要作为参数在对象间传递消息。通常是临时对象在操作结束后就可以被丢弃。值对象可以作为实体的属性例如一个人是一个完整的实体而他的名字则是值对象。当然也并非意味着值对象是一个单纯的属性实际上值对象是指某一个特定概念下具有完整意义的、通过属性进行理解的对象。例如地址由省、市、区、街道、邮编等综合属性组成这些组成对象实际上也是实体他们联系起来就组成了值对象。 5 服务 在软件设计中并非所有的对象都需要通过标识或属性进行区分。领域驱动设计中使用服务Service)来定义具有活动或动作的对象。事实上也确实如此并非所有的对象都适合使用实体或值对象来进行建模。服务强调与其他对象的操作是通过定义能够为使用者做什么来实现的。也就是说服务倾向于动词领域而非名词领域。 5.1 服务对象的基本特征 按照领域驱动设计的说法一个好的服务应该具有以下特征 1与领域概念相关的操作不是Entity或ValueObject的一个自然组成部分。 2接口是根据领域模型的其他元素定义。 3操作是无状态的。操作的无状态是指任何调用者都能使用而无需关注实例的历史状态。5.2 服务与领域层 在领域涉及中服务无处不在大体上包括以下几种不同层次。 1、应用层定义与应用相关的基础服务例如在处理资金转账业务时定义一系列服务1、包括获取输入2、发送消息给领域层服务由其完成动作的执行3、监听确认消息等。 2、领域层处理与相关的服务例如处理有上述转账业务发起的请求例如进行结果的确认等。 3、基础设施层发送消息通知。 5.3 服务的粒度 在概念建模中通过控制领域层中接口的力度可以有效的实现客户端与实体和值对象的耦合。通过合理的模式确保接口的简单性将便于在大型或分布式系统中对组件进行打包的粒度控制这实际上也是微服务架构中服务粒度细分的理论基础。6 包或模块 模块是软件工程学中自古有之的基本概念。在软件系统设计中经常会按照各种各样的类别进行分解有时候按照技术架构来分割有时候则按照开发者的任务例如按照用例来进行细分有的在软件重构过程中甚至会沿用历史架构早期形成的模块划分。 在软件工程学中高内聚低耦合是基本的概念而在模块之间的关系成为耦合而模块内部的关系成为内聚。因此好的软件项目模块之间应该低耦合而模块内部则应该高内聚。但是模块的划分跟软件分层划分一样不应该仅仅只是代码层面的划分而应该是概念模型角度的划分。不连贯的思想或者“一锅粥”式的模块划分最终只会造成系统开发的严重不可控。 领域驱动设计认为模块是一种非常重要的表达机制。模块的选择应该取决于被花费到模块中的对象的意义。当某些对象在模块中被创建时实际上相当于告诉下一位开发者这些对象间是通过模块来实现了某种关系。 选择能够描述系统的模块并使之饱含一个内聚的概念集合。应该基于模块来实现概念组合的方式从而可以向相互独立地理解和分析这些概念。对模型进行精化直到可以更具高层领域概念对模型进行划分同时相应的代码也不会产生耦合。7 结论 随着系统设计规模和复杂度的增加模块化变得更加重要。领域模型中的每个概念都需要在实现元素中反映出来。实体、值对象、他们之间的关联关系、领域服务以及用于组织元素的模块都是实现领域模型相对应的地方。实现中的对象、指针和检索机制必须直接、清楚地映射到模型对象。相关文章领域驱动设计让程序员心中有码领域驱动设计让程序员心中有码二领域驱动设计让程序员心中有码(三领域驱动设计让程序员心中有码四原文地址: https://www.cnblogs.com/xiyuanMore/p/10230801.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
