应城网站建设,餐饮营销手段13种手段,常用网站开发软件6,珠海蓝迪装饰公司官网本文以餐厅场景为叙事主线#xff0c;以领域驱动为核心思想#xff0c;结合架构设计与功能设计方法论。是从领域分析到落地的全过程案例#xff0c;内容偏重于落地#xff0c;因此不乏一些探讨#xff0c;欢迎指正。
文章较长、全程干货、耐心读完、必有收获。
本文不针…本文以餐厅场景为叙事主线以领域驱动为核心思想结合架构设计与功能设计方法论。是从领域分析到落地的全过程案例内容偏重于落地因此不乏一些探讨欢迎指正。
文章较长、全程干货、耐心读完、必有收获。
本文不针对餐厅的实现细节重在探讨设计思想和方法。 1、领域设计
让我们抛开技术人员的本能技术视角、站在纯业务视角来分析领域问题。
领域设计的核心是分而治之目的是实现业务领域的自治性。
就像你平时不会将枕头和被子放在厨房或卫生间一样你的床上不会放着大米白面否则你想睡觉是一件很复杂的事情软件系统也是如此这就是我们要解决的问题。 1.1 宏观流程
假如我要设计一个餐厅由于分而治之的需要我会首先从宏观流程去分析可以帮我们迅速找到重要的区域。 因此会得到几个明确的行为区域我将餐厅划分为“菜品域”“订单域”“厨房域”“用餐域”这是业务级别的领域划分后续应该针对每个区域单独分析。
产出物是宏观流程和参与角色 1.2 统一语言
语言贯穿于整个开发过程从需求分析到设计、从设计到编码因此好的语言非常重要好的语言体现了清晰的业务概念。
在这个阶段我们需要通过梳理找到业务中都有哪些实体与行为对其做一些归纳。我们的核心问题是“谁”通过什么“行为”影响了“谁”其中的三个要素分别是角色、行为、实体。 我的建议是先找到 “角色”、“实体”、“行为”并对其归类我常常关注角色以及具体身份、实体以及实体实例功能以及包含的重要步骤。
角色是施事主语、是名词是主动发起行为的一类实体。
行为是动词、是做了什么事情是行为本身。
实体是名词是除“角色”之外的其他实体。
推荐使用脑图画出来我认为归纳后的脑图有助于我们识别根本要素有利于抽象。
产出物是名词、概念定义、相关脑图。 1.3 用例分析
在这一步、我们使用相对宏观的分析不需要进入用例的细节分析掌握角色与行为之间的关系理清谁在做什么角色的职责差异是什么。
产出物用例图
以做菜为例如图 1.4 领域划分
我们在分析宏观流程时划分了几个行为区域但那是业务级别的。在那基础之上我们需要拉进某个区域的视角再结合之前的用例分析按照“功能相关性”、“角色相关性”进一步划分领域。
功能相关性是用例与领域之间的关系任何业务的领域都是由一套用例组成的所以领域划分以功能相关性为主例如与做菜相关的用例都应该归属于厨房所以我们确认了厨房域确认了厨房域包含的用例这是很自然的事。
角色相关性其次是角色常用于划分子域某个区域涉及多个角色参与可以按照角色的分工拆分为多个子域从而满足不同角色的个性化需要。例如厨房的采购人员负责买菜、刀工负责切菜、大厨负责烹饪。我们就会考虑将厨房划分为“采购域”、“加工域”、“烹饪域”。
通常来说子域不具备独立的问题空间不会作为独立的领域存在。
产出物领域、子域
以厨房域为例如图 1.5 领域建模
这是大家比较熟知的阶段重点分析实体与领域之间关系领域聚合实体与实体的关系OO聚合。
领域模型是实现功能的基石、需要有对功能的本质理解才能找到最核心的实体实体之间的OO聚合关系决定了功能的扩展性OO聚合是最重要的核心点。 组合、聚合
聚合aggregation聚合关系是一种弱的关系整体和部分可以相互独立。
组合composition组合关系是一种强的整体和部分的关系整体和部分具有相同的生命周期。
可以使用如下案例既能表达领域聚合又能表达OO聚合的关系。 产出物聚合、实体、值对象、实体的属性
领域服务和事件在后续的功能设计中提供 1.6 领域上下游
领域上下游关系不是领域的依赖关系依赖关系指的是能力的依赖是共用了某些能力依赖关系是固定的。领域上下游关系也不是调用关系调用关系是与用例相关的并非描述领域处境的。
领域上下游关系指的是影响力的关系上游影响下游影响力分为“逻辑影响”和“数据影响”一般说来我们更应该关注“数据影响”所以领域上下游关系是一种数据流向的限定是业务发生的顺序限定用于规定该领域所使用的数据是下游领域依赖上游领域“准备就绪”的体现。合理的上下游限定有助于减少领域之间的不必要依赖有利于数据的复用并减少重复计算。
领域上下游是与场景相关的并不是一成不变的不同的场景存在不同的上下游各场景应该独立说明。
产出物各场景的上下游说明 例在【菜品管理】场景下 如果厨房的某些食材不足了或者某个厨师休假了就会影响到菜品的展示从而影响到客户的订单。 例在【客户消费】场景下 客户的订单、影响厨房生产的菜从而影响刀工的行为也影响到了采购。 请对比下面两个图用于理解领域的上下游 实际上厨师不应该依赖采购人员的采购功能也不依赖刀工的切菜功能他只是依赖“初加工食材”而已而“初加工食材”就是被处理好的数据厨师在做饭时“初加工食材”就已经被处理好了上面的图例只是为了说明一个关于领域上下游的问题这是业务发生顺序以及数据来源的问题。
我们常常使用领域事件串联业务流程在使用领域事件时不止要关注点对点的解耦更应该使业务流程符合领域上下游限定让各个领域独立运行减少领域之间的功能依赖降低领域之间的耦合减少业务变化带来的影响。 2、架构设计
架构设计是为了解决软件系统复杂度带来的问题找到系统中的元素并搞清楚他们之间关系。
架构的目标是用于管理复杂性、易变性和不确定性以确保在长期的系统演化过程中一部分架构的变化不会对其它部分产生不必要的负面影响。这样做可以确保业务和研发效率的敏捷让应用的易变部分能够频繁地变化对应用的其它部分的影响尽可能地小。
架构设计三原则合适原则、简单原则、演化原则
2.1 分层架构
我们需要按照 接口层、领域层领域用例层、领域模型层、依赖层、基础层 构建架构模型。
接口层为外部提供服务的入口是适配层的北向网关。不实现任何业务逻辑也不处理事务是跨领域的是流程编排层是门面服务。
领域用例层是领域服务层是领域用例的实现层、隶属于某个领域、是业务逻辑层是事务层业务逻辑应该在这层完整体现不要分散到其他层级。
领域模型层是领域模型实体、值对象、聚合的所在位置专注于领域模型自身的能力不包含业务功能可以处理事务是原子化的能力是领域对象的自我实现。
依赖层 是连接外部服务的出口是适配层的南向网关。包括仓储端点、RPC等主要作用是领域和外部解耦用于保持领域的独立性是跨领域的。
基础层与业务无关的与领域无关的通用的技术能力技术组件等。 2.2 架构映射
架构的视角从大到小依次是系统-应用微服务-模块包-子模块 这样的从大到小的层级。
业务领域映射我们将划分好的领域按照对应的视角映射为对应的元素领域模型映射到架构模型时应该是视角对等的如果餐厅是系统、那么厨房就是应用如果餐厅是应用、那么厨房就是模块。也应该层级匹配的将用例的实现映射到用例层将领域模型的实现映射到领域模型层。
技术和抽象问题有时候、业务领域分析不能体现那些共性的技术问题所以需要适当结合技术视角可能需要对领域模型微调。同时、我们需要找到共同需要的基础能力例如“水”、“电”、“煤气”等等将这些作为额外的考虑因素要做到业务问题与技术问题解耦不要将技术问题和业务逻辑揉成一团。
领域设计类似餐厅设计师他设计餐厅有几个区域区域的用途是什么。
架构设计类似建筑设计师他设计如何走水电煤气、如何施工等。
产出物分层架构图 以厨房为视角其架构如下 以餐厅为视角其架构如下 分层架构图体现逻辑上的层级分布而不是代表组件的具体含义组件是应用还是模块、需要结合实际情况而定。 2.3 必要的约束
1、分层架构越往下层就越是稳定的下层是被上层依赖的下层不可以反向依赖上层扩展点除外。因为分层架构的核心原则是将容易变化的逻辑上浮将共性的、原子化的、通用的逻辑下沉被依赖的下层应该是稳定的这要求上层承接更多业务变化。下层离开上层应该是可以独立存在的例如在接口层定义的DTO不可以在下层被使用但领域层定义的实体可以被上层使用。
2、在使用充血模型时应该符合面向对象编程原则不要随意的将一些能力都充到领域实体模型中。以“菜”为例重量和规格是“菜”的自身的属性激发味蕾是“菜”的能力“菜”可以维护自身的持久化状态。但是、请注意、“菜”不可以“炒菜”因为“炒菜”的时候“菜”还没有出现呢“菜”不是自己的上帝“菜”需要被做出来所以“菜”被做出来之前是没有“菜”的这是个时间上的概念不要错把“炒菜”的能力放在“菜”的身上。“炒菜”用到的“水电气食材调料厨具”不应该是“菜”的属性范围这些元素都在“厨房”的范围中不要让领域的模型包含不属于自身的元素领域的实体模型只是领域的一部分只用于实现通用的模型能力。
3、接口层和依赖层是与领域无关的他们是与技术相关的层级不属于任何领域这两层不能包含业务逻辑。有时候我们可以把接口层拆为两层接口层应用层也可以把依赖层拆分为两个模型依赖、服务依赖。
4、领域层是与环境无关的无论某个领域是应用还是模块都应该具备独立的用例层和独立的模型层即使多个领域在同一个应用当中也要按照他们是分别独立去看待无论某个领域是应用还是模块领域对外部的交互不可以绕过依赖层和接口层。
5、领域应该是最小完备的把一个领域拆分为子域、子子域、子子子...... 无限拆分拆分到一定程度之后某个子域就不完整了不完整的子域是不可以独立存在的。拆分不不够或者过度拆分都是不符合低耦合高内聚原则的。当一个领域的内部子域不具备独立性时他们之间不必严格解耦不需要通过依赖层访问本领域的其他子域他们之间可以直接调用。
6、领域服务层就是领域用例层他们俩是同一回事儿都是用于实现领域内的用例的。不要将领域服务与领域用例视为两个独立的层也不要将领域服务与领域模型视为同一层否则会导致逻辑的分散一部分在领域服务层、一部分在领域模型层、还有一部分可能在用例层也会导致每个层的职责不明确容易搞乱。如果将业务逻辑写在领域模型中会导致业务逻辑进一步下沉业务逻辑的不确定性太大是不适合下沉的是违反分层架构原则的。领域模型对应的是实体、领域服务对应的是用例。
7、领域用例层只能承接符合自身领域的用例我们划分出领域的目的就是为了区分每个领域的职责所在因此他们必须严格按照职责办事我们在之前已明确了用例和领域之间的关系需要严格遵守。
8、领域模型层遵循最小依赖原则只可以依赖必要的资源必要资源指的是领域模型实现自身能力需要的资源不包括实现业务逻辑包含的资源。例如领域模型需要依赖DB完成持久化可以依赖数据访问资源但不应该依赖其他领域资源、不可以依赖RPC资源等。 2.4 微服务划分
服务划分以领域划分为参考主要看我们要拆分到什么粒度这 应该符合低耦合高内聚原则不破坏领域实体的聚合关系。
产出物微服务 例如餐厅是有必要拆分的餐厅的“菜品域”“订单域”“厨房域”有独立的问题空间。
例如厨房是没有必要拆分的厨师与刀工的耦合非常高他们都在做饭分开之后是不完整的分开就是没有必要的。 所以餐厅被拆分为厨房Kitchen、菜品Category、订单Order三个微服务。
基于此、我们单独拿出餐厅门面服务作为接口层应用再单独拿出餐厅基础服务作为水电煤气的应用。
一般情况下依赖层不会作为单独的服务提供会被以组件的形式嵌入到其他服务中。 3、功能设计用例实现
如果说领域设计是餐厅的设计师、架构设计是餐厅的建筑师、那么功能设计就是餐厅的厨师或服务员。
任何设计都要落地到功能设计如果厨师不守规则偏偏要去洗手间洗菜最后的结果依然是一团乱最终会导致设计无法落地。
功能设计是实现 “面向扩展开放、面向修改关闭” 的途径是指导研发落地必备环节。 3.1 功能的概念
功能迭代时功能会发生一些变化所以他的含义是可能变化的所以我们需要再次审视功能的概念及时加以调整。
例如、我们实现了一个“做蛋炒饭”的功能后来又实现了一个“做辣椒炒蛋”的功能那么我们应该将功能升级为“炒菜”甚至是“制作菜品”等。
明确功能的概念是功能设计的前提。
产出物更新语言库更新脑图 3.2 用例的位置
我们在领域分析章节已明确了用例与角色的关系用例与领域的关系。
然而一个新功能的加入我们仍然要再次评估以确保他处于正确的位置。
产出物更新用例图 3.3 事件风暴
我们需要深入功能的细节首推的方法是事件风暴适用于解构复杂功能。
事件风暴的作用并不限于功能分析只是我觉得很适用于功能分析事件风暴的一张图包含很多内容正好是功能设计所需要的。
将功能拆分为多个子功能步骤。在后续使用
确认参与该步骤的角色和领域。在后续的3.6章节落地
确认步骤的串联流程和领域事件。在后续的3.6章节落地
确认参与该步骤的领域实体。在后续的3.7章节落地
产出物事件风暴模型 3.4 用例分析
我们暂且收回思路首先要关注共性和差异问题以确保功能的扩展性。
确认用例的泛化差异点实现功能的扩展。
寻找共同包含的步骤实现逻辑的复用。
产出物用例分析图 例制作菜品做大拌菜、做铁锅炖、做炒鸡蛋、做蒸米饭、做炒米饭 3.5 用例实现类领域服务类结构图
专注于用例层的类设计实现“面相修改关闭面相扩展开放”。
用例的类结构图是用例分析图的一种映射。
出物用例层的类结构图 3.6 用例流程图
我们接回思路更进一步将事件风暴模型落实到代码层面。
我们将步骤分配到实现类中、步骤就是该类的一个方法进一步明确由哪个类和方法来实现该步骤从而就规定了步骤所在的领域。
我们将步骤和领域事件串联起来规定了业务实现流程。推荐使用泳道图表达上述内容。泳道的纵向组件是用例的实现类。
这是真实业务流程的映射。
产出物用例流程图 以炒鸡蛋为例其用例流程图如下 3.7 活动图时序图
我们进一步将事件风暴模型落实到代码层面我们使用时序图体现依赖和调用关系规定了步骤与领域实体模型的关系进一步说明用例是如何实现的。
这时候为了简便、我们可以收起领域服务类用例层的泳道。
产出物时序图、活动图 试想一下、假如把业务逻辑放在领域模型当中例如聚合如何实现“面相扩展开放、面相修改关闭”呢 4、编码实现
编码实现...... 我决定还是...... 偷个懒吧...... 哈哈哈。
但是我们回顾一下之前的内容是否足够了 不同的研发人员依照设计去编码是否会写出不一样的代码 系统名
餐厅系统
相关应用
厨房应用、菜品应用、订单应用门面应用、基础应用
系统架构图 厨房应用-领域模型 厨房应用-用例层
厨师模块、刀工模块、买菜员模块
厨房应用-用例层-厨师模块服务类结构 厨房应用-用例层-厨师模块类中的方法、方法含义、执行流程 厨房应用-用例层-厨师模块方法的依赖、调用关系 最后、我们的目标是“解决软件复杂度带来的问题”而实现这个目标的途径是“设计指导研发落地”。
