架构师篇 DDD领域驱动设计篇

一 DDD领域驱动设计

1.1 领域驱动设计

领域驱动设计(英文:Domain-Driven Design,缩写DDD)是一种模型驱动设计的方法领域驱动设计常以战略设计与战术设计来将整个领域展现的淋漓尽致,其作用范围既面向业务也面向技术。从战略角度(个人更喜欢称其为上帝视角)去规划系统、划分领域。而从战术角度则从技术层面来指导我们该如何去设计。

功能作用:

1.通过模型直接反映软件的结构;2.以模型基础形成团队的统一语言;3.把模型作为精粹的知识用于传递。

领域驱动设计的核心在于领域建模,架构师的水平高低在很大程度上也体现在领域建模水平上。

1.2 mvc架构

对于业务逻辑不复杂的软件开发,MVC是简单高效的方法。但是随着业务逻辑愈来愈复杂,MVC会开始力不从心。主要体现在这几个方面:

1.MVC模式仅仅反应了软件层面的架构,它不包含业务语言,无法使用该设计直接和业务对话。

2.MVC模式天然切割了数据和行为,然后用数据库实现数据,用服务实现行为,容易造成需求的首尾分离。

3.缺乏明确的边界划分,至少在顶层设计层面没有边界划分的规范要求,更多地是靠技术负责人根据经验进行划分,大规模团队协作容易出现职责不清晰、分工不明确。

1.3 DDD的作用*

1.统一语言:

团队(业务方、产品、设计、技术等)在一个限定的上下文中有意识地形成对事物统一的描述,从而形成统一的概念(模型)统一语言用于需求文档、PRD文档、系统分析文档、代码以及日常沟通中,统一的概念和术语可以极大地提升沟通效率和工作效率。

2.面向业务建模:

领域模型和数据模型分离,业务复杂度和技术复杂度分离。DDD聚焦于领域模型,将技术实现细节从模型中剥离出来,能够更好地降低业务和技术的耦合度。

3.边界清晰的设计方法:

通过对需求的识别及分类,划分出领域、子域和限界上下文,进而指导团队成员分工协作,从而做到将复杂的问题分而治之地解决。

4.业务领域的知识沉淀:

通过模型与软件实现关联,统一语言与模型关联,反复论证和提炼模型,使得模型与业务的真实世界保持一致,从而促使业务知识通过模型得以传递和沉淀,https://zhuanlan.zhihu.com/p/641295531

1.4 领域通用语言

需要确保团队使用的语言在所有的交流形式中看上去都是一致的,这种语言被称为“通用语言(Ubiquitous Language)”。通用语言应该在建模过程中广泛尝试以推动软件专家和领域专家之间的沟通,从而发现要在模型中使用的主要的领域概念。

1.5 DDD笔记总结

1.5.1 DDD的作用

1.ddd是领域设计:ddd是通过领域驱动设计方法定义领域模型,从而确定业务和应用边界,保证业务模型与代码模型的一致性。

Ddd不是架构,而是一种架构设计方法论,它通过边界划分将复杂业务领域简单化,帮我们设计出清晰的领域和应用边界,可以很容易地实现架构演进。

概述:不是一种架构,而是一种架构方法论,是一种拆解业务,划分业务、确定业务边界的方法,是一种领域设计思想。核心思想是领域模型,避免业务逻辑的复杂度与技术实现的复杂度混淆在一起。如在不同场景中,我们对同一个事物的称呼也有较大差异。例如,商品、货物;同样一个东西,在交易领域叫做商品,在物流领域叫做货物。

2.ddd的范围:

战略设计主要从业务视角出发,建立业务领域模型,划分领域边界,建立通用语言的限界上下文,限界上下文可以作为微服务设计的参考边界。

战术设计从技术视角出发,侧重于领域模型的技术实现,完成软件开发和落地,包括:聚合根,实体,值对象,领域服务,应用服务和资源库等代码逻辑的设计和实现。

3.闲谈吹牛格局

DDD思想精髓值得软件工程师以及架构师们领会,即:

1.直接面向业务进行领域建模,将业务知识沉淀到领域模型中。业务知识的沉淀不是一蹴而就,应该反复提炼,持续演进;为了让演进提炼的过程高效顺畅,团队使用统一语言来沟通、描述需求和设计方案。

2.高内聚、低耦合是应对软件复杂度的不二法则领域、子域、限界上下文、聚合都是为这条宗旨服务的工具。

3.深刻理解业务,洞察问题本质才是一个架构师最核心的能力体现。寻找领域模型,提取统一语言,做分层与隔离。

1.5.2 贫血模型和充血模型*

1.贫血模型:只包含数据,不包含业务逻辑的类。

2.充血模型:既包含数据,也包含业务逻辑的类。

1.5.3 mvc与ddd的区别* 

 1.5.4 应用层和服务关系*

1.5.5 ddd的工程架构层级说明 

1.层级概述

2.层级功能说明

1.5.6 ddd的领域划分

1.领域的拆分

2.领域

3.领域

1.6 DDD的工程架构

1.6.1 工程概览

分为:接口层,应用层,领域层,基础设施层。

1.6.2 接口层

1.6.3 应用层

1.6.4 领域层

1.6.5 基础层

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
领域驱动设计(Domain-Driven Design,简称DDD)是一种软件开发方法论,旨在解决复杂业务领域的软件开发问题。它强调将业务领域的知识和概念直接融入到软件设计和开发中,以实现更好的业务价值和可维护性。 在C#中实施DDD时,可以采用以下几个关键概念和技术: 1. 领域模型(Domain Model):领域模型是DDD的核心概念,它是对业务领域的抽象和建模。在C#中,可以使用类和对象来表示领域模型,通过定义实体(Entity)、值对象(Value Object)、聚合根(Aggregate Root)等概念来描述业务领域中的实体和关系。 2. 领域驱动设计的分层架构DDD通常采用分层架构来组织代码。常见的分层包括用户界面层(UI)、应用服务层(Application Service)、领域层(Domain Layer)、基础设施层(Infrastructure Layer)等。每一层都有不同的职责和关注点,通过良好的分层设计可以实现代码的可维护性和可测试性。 3. 聚合根和聚合:聚合根是DDD中的一个重要概念,它是一组相关对象的根实体,通过聚合根可以保证一致性和边界。在C#中,可以使用类来表示聚合根,通过定义聚合根的行为和关联关系来实现业务逻辑。 4. 领域事件(Domain Event):领域事件是DDD中用于描述领域中发生的重要事情的概念。在C#中,可以使用事件(Event)或委托(Delegate)来表示领域事件,并通过事件驱动的方式来处理领域事件。 5. 仓储(Repository):仓储是用于持久化和检索领域对象的接口或类。在C#中,可以使用接口和实现类来定义仓储,并通过依赖注入等方式将仓储注入到其他类中。 6. 领域服务(Domain Service):领域服务是一种用于处理领域逻辑的服务。在C#中,可以使用类和方法来表示领域服务,并将其注入到其他类中使用。 以上是DDD领域驱动设计在C#中的一些关键概念和技术。通过合理运用这些概念和技术,可以更好地实现复杂业务领域的软件开发。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值