领域驱动设计应用 - Perficient数字化落地实践

Posted 博克软件

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了领域驱动设计应用 - Perficient数字化落地实践相关的知识,希望对你有一定的参考价值。

自从有了软件设计、软件开发这一类工程实践活动,业界就没有停止过探索如何更有效、简单且优美地解决软件工程化问题。UML建模方法和工具也曾经风靡一时。今天要聊的是一种古老而又现代的领域建模技术-领域驱动设计Domain-Driven Design。古老是因为这个方法在很早前就提出了;现代是因为随着近些年微服务的发展,DDD这一设计工具又重新焕发了活力。

说到DDD,那就不能不提到Eric Evans这位先驱。想深入了解他的思想,建议购买一本他写的书《领域驱动设计》。你可能会觉得这本书写的相当理论,但书里也提供了一些软件设计的案例。当然,最好的方式是理论联系实际,界定哪些是应用中核心要素,哪些是可以根据实际情况来做裁剪。


领域驱动设计应用 - Perficient数字化落地实践


从DDD概念入手

先来看一组DDD领域驱动设计里的概念。DDD的指导文档里有很多概念,至少20多种。对于大部分的使用者来说,难以在很短的时间内全部应用。建议对基本的意思进行了解,并且结合你的应用加深理解。

Bounded Context界限上下文

对特定模型的边界描述,比如一个子系统,或者一个特定团队的工作集合。书中列举的细胞膜和细胞壁的例子,还是非常形象的。

Ubiquitous Language统一语言

这是跟领域模型紧密相关的结构化语言,在一个有界限上下文中,所有团队成员都是用这种语言来形成共识。注意,这里的通用语言是指在一个界限上下文中。

Continuous Integration持续集成

这个概念跟敏捷中的CI没有太大的区别。在一个复杂的项目中,可能团队众多,各自工作在其中的一个领域,就会产生一致性的问题,对不同部分的工作成果(代码)需要进行高频度地集成,越早越频繁的进行,就能更好地消除差异,降低风险。

Hexagonal Architecture六边形架构

一个六边形架构共包括三个层,其中最关键是的领域模型,它包括了所有的应用逻辑与规则;领域层之外的是端口层,它负责接收与用例相关的所有请求;在端口层之外的是适配器层,这一层的技术实现负责以某种格式接收输入、及产生输出。并且在微服务的设计中,六边形很好的对应到一个界限界限上下文,与服务容器切割有着天然的对应关系。

领域驱动设计应用 - Perficient数字化落地实践

图来自:《实现领域驱动设计》


界限上下文之间也存在着一些映射关系,从更广的视角来看,需要考虑战略设计,分层架构,上下文映射,领域事件等方面。


领域设计在微服务中的应用体会

对应到单体结构的工程,微服务强调的是服务的切分,或者说是业务领域的划分。比如说产品的定义,属性周期管理是一个领域,可能单独有产品组来维护和应用开发。而客户的系统是另外一个领域,二者会存在一定的映射关系。在我们的落地实践中,我们有用户鉴权服务、产品注册服务、用户活动服务、广告服务、数据分析服务等。这一些服务,本身都可以构成一个六边形架构,有核心领域、应用逻辑与端口,以及外部的适配器。适配器的形式为不同服务间基于JSON格式的API调用。在数据层,除了产品,其他领域共享一个存储库。结合我们的敏捷及DevOps实践,下边是我们的一些应用体会。

1.合还是拆?

在项目初期,对于一些服务界限上下文与微服务合还是拆,项目组有很多的争论。敏捷本身的出发点是强调增量迭代,根据我们获得的经验,我的建议是:如果在业务分析阶段能够很清晰的界定出某些领域是天然的单独服务,比如我们这里产品管理注册是属于特定用户群体访问,模型有着自己的边界,就自动形成自己的微服务;如果边界比较模糊或者现在还不确定,先不要拆,随着项目的演进,不断运用DDD对架构进行迭代更新。

2.组成特性团队配合微服务开发。

领域、户故事组以及微服务的容器在逻辑上都是有着一一对应关系的,这样很适合组成特性团队。比如说一个前端、一个后端和一个测试人员组成产品注册的特性开发团队,那么从需求导入、功能开发、测试和自动化部署均由这个组来完成。当然,在人员不多的情况下,肯定存在人员共享,比如说队员A,在这个星期专注在功能A上,下一周轮换到其他功能。


3.使用微服务并不意味着不需要整体领域设计。

敏捷中的代码和架构可以进行重构,但是重构是需要付出时间的代价,而且重构之后需要进行评审和回归测试。特别是对时间线要求很紧迫,预算有限的项目,一开始就对整体有初步设计,会使得项目推进更顺利。这里着重是指业务架构的设计,还有各个微服务之间的交互,以及与其他已存在系统的集成设计。举例说,每个系统都会有数据分析、报表的功能。在微服务的环境下,如果数据存储都是异构的,格式不一,会给数据分析带来一定的挑战和难度。


限于篇幅,其它方面的痛点和体验不一一展开细说。我相信每一个项目和业务系统落地都有其独特性挑战。DDD和微服务不是银弹,但其理论来源于之前的实践,再返回实践,相信引入这一套方法会给项目带来价值。Perficient中国团队专注于帮助客户导入敏捷实践,运用业界最佳方案、架构帮助项目落地,响应业务方的持续多变。如果您的企业有类似的痛点和需求,可以联系

ChinaGDCSales@perficient.com

来详细聊聊您的需求。


如需转载注明出处




 


以上是关于领域驱动设计应用 - Perficient数字化落地实践的主要内容,如果未能解决你的问题,请参考以下文章

云原生时代,领域驱动设计思想(DDD)如何落地?

谈谈DDD(领域驱动设计)

谈谈DDD(领域驱动设计)

基于ABP落地领域驱动设计-06.正确区分领域逻辑和应用逻辑

实现领域驱动设计

DDD(领域驱动设计)从入门到精通