首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

DDD领域驱动设计在微服务架构的应用

我们都自诩面向对象编程,OOP思想更是熟读于心,然而随着业务日益复杂,代码越来越臃肿,这时感觉之前面向对象的理论也毫无用武之地。到底哪个环节出问题了?笔者认为造成这种局面的原因很大程度是我们忽视了业务建模和设计的重要性。我们通常启动一个项目后,架构师等技术人员会拿到产品人员的产品需求然后开始各种建模、各种拆分,也是在技术内部形成共识和就进入实施阶段。这实际就犯了一个严重的错误:技术和业务未达成业务模型的共识。2003年Eric Evans发布首版《领域驱动设计》实际就为了解决这个问题。领域驱动设计更大层面是提供了方法论的支持,所以在具体实施各有不同。今天我们就介绍下我们在实践过程领域驱动设计的一些经验与心得。

02

CQRS架构

CQRS(Command Query Responsibility Segregation),命令查询责任隔离。我最初听到的是Greg Young描述的一种模式。其核心思想是,可以使用与用于读取信息的模型不同的模型来更新信息。在某些情况下,这种分离可能很有价值,但请注意,对于大多数系统,CQRS会增加风险的复杂性。 人们用于与信息系统进行交互的主流方法是将其视为CRUD数据存储。我的意思是说,我们具有某种记录结构的思维模型,可以在完成处理后创建新记录,读取记录,更新现有记录以及删除记录。 在最简单的情况下,我们的交互都是关于存储和检索这些记录的。随着我们的需求变得越来越复杂,我们逐渐摆脱了这种模式。我们可能希望以与记录存储不同的方式查看信息,也许将多个记录折叠成一个记录,或者通过组合不同位置的信息来形成虚拟记录。在更新方面,我们可能会发现验证规则,这些规则仅允许存储某些数据组合,甚至可能推断出与我们提供的数据不同的数据。

01

微服务业务开发三个难题-拆分、事务、查询(下)

上集:微服务业务开发三个难题-拆分、事务、查询(上) 上集我们阐述了使用微服务体系架构的关键障碍是领域模型,事务和查询,这三个障碍似乎和功能拆分具有天然的对抗。只要功能拆分了,就涉及这三个难题。 然后我们向你展示了一种解决方案就是将每个服务的业务逻辑实现为一组DDD聚合。然后每个事务只能更新或创建一个单独的聚合。然后通过事件来维护聚合(和服务)之间的数据一致性。 在本集中,我们将会向你介绍使用事件的时候遇到了一个新的问题,就是怎么样通过原子方式更新聚合和发布事件。然后会展示如何使用事件源来解决这个问题,

013
领券