个人中心
文章发布
退出
作者热门文章
- VisualStudio2022插件的安装及使用-编程手把手系列文章
- pprof-在现网场景怎么用
- C#实现的下拉多选框，下拉多选树，多级节点
- 【学习笔记】基础数据结构：猫树
57
4
本文书接上回《反DDD模式之关系型数据库》，关注公众号（老肖想当外语大佬）获取信息:
最新文章更新； 。
DDD框架源码（.NET、Java双平台）； 。
加群畅聊，建模分析、技术实现交流； 。
视频和直播在B站.
在我们软件开发过程中，“复用接口（webapi）”、“复用服务（service）”是非常常见的现象，很多老司机都会为自己设计的代码可以“复用”而感到有成就感。然而当我们在一个较长的时间周期去看待系统的迭代过程，会发现这些“复用”，往往会成为后来迭代的绊脚石，修改代码牵一发而动全身，细微的修改也会引发广泛的影响面，从这个角度看，“复用”是不利于系统的可维护性的.
今天我们就来深度探讨一下“复用”和DDD之间的关系，打开一个不同的视角.
下图展示了一个非常典型的复用例子，不少开发者习惯提供一个“保存接口”来满足“创建”和“编辑”场景:
按照我们的惯例，“连线”代表着“耦合”，所以“复用”接口，本质上就是把不同的业务场景耦合在了一起，当一个场景发生变化时，同时会影响到其它场景.
进一步地推导，两个元素的耦合即打破它们的边界，它们因为耦合而成为了一个更大的整体:
而DDD的价值观是保持明确的边界，打破边界则与之完全相反，因此可以得出打破边界即反DDD:
把上面的推导过程整合在一起就是下图这样:
去掉中间过程，最终我们得出标题的的结论“复用”是一种“反DDD模式”:
另外一方面，“复用”一词的含义还是比较广泛的，例如我们有两个系统，A系统和B系统都调用某家的“支付接口”，这算不算复用“支付接口”呢？在我们今天讨论的角度看，这不算复用，因为都是“支付场景”调用“支付接口”，场景其实是同一个.
那么我们需要限定一下范围，这里探讨的复用是指：为不同的场景或者目的所做的复用。基于这个范围我们可以看到一些典型的复用案例:
RestfulAPI复用 。
后端服务复用 。
业务中台复用 。
而这些场景，我相信很多老司机都有过痛彻心扉的体验，复用一时爽，迭代火葬场.
基于前面推导的认知，我们知道复用作为反DDD模式，并不会为我们带来价值，反倒会使得系统丧失可维护性，因此我们在实践DDD过程中总结了一些原则，其中重要的部分就是“不要复用”:
为每个前端场景创建一个API； 。
为每个API创建各自的输入输出实体（RequestDto、ResponseDto）； 。
为每个操作创建各自的命令（Command）； 。
下面贴出DDD原则的文档和截图:
https://netcorepal.github.io/netcorepal-cloud-framework/rules-of-ddd/rules-of-ddd/ 。
目前开源DDD实战项目d3shop已经启动了，你可以自由地参与需求讨论、建模设计、代码贡献中来，我们每周都会针对模型设计、代码做直播评审和连麦讨论，从而帮助你更沉浸地体验DDD实践带来的成长和收益.
项目代码：https://github.com/netcorepal/d3shop 。
最后此篇关于反DDD模式之“复用”的文章就讲到这里了,如果你想了解更多关于反DDD模式之“复用”的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。
57
4
0
这里有一个很大的设计缺陷，但我无法解决它: 业务需要有点涉及，所以我会尽量保持简单。 我们有一张购物表和一张退货表。当进行退货时，我们必须找到与数据库中最早购买的退货匹配，并将其记录在“已应用退货”表
在我的家庭项目中，我遇到了确定域对象类型的问题。 领域:公交时刻表 限界上下文:路由(公共(public)交通基础设施，ctx1)、时间表(调度，ctx2) 对象: Station - 描述一个公交车
我有一个名为“产品类型”的值类型，它被分配给了一个产品。 (一个产品有一个产品类型) 为了允许用户从列表中选择类型，我将填充一个下拉列表。在哪里检索产品类型列表最合适？一个实现存储库模式的类？ 编辑:
域这个词在 DDD 中究竟是什么意思？我一直在阅读定义……虽然我看到了域模型之类的东西并理解模型是什么 - 域模型是什么意思？ 域实际上是什么意思？ 谢谢 最佳答案 域是指您的应用程序解决的主题。 例
DDD 中的域模型应该与持久性无关。 CQRS 要求我为我不想在读取模型中包含的所有内容触发事件。 (顺便说一下，将我的模型拆分为一个写模型和至少一个读模型)。 ES 要求我为所有改变状态的事件触发事
Eric 在他的书中触及了 的主题。模块 很少。他也没有通过示例讨论模块结构与有界上下文的关系。限界上下文是否包含模块或模块包含限界上下文？当应用程序具有 DDD 时，它的可扩展性有多容易？ 在我们设
前言 笔者于2021年入职了杭州一家做水务系统的公司，按照部门经理要求，新人需要做一次个人分享(主题随意)。 当时笔者对DDD充满了浓厚的兴趣，之前也牛刀小试过，于是就决定班门弄斧Show一下
上部分 模型驱动设计的构造块 为维护模型和实现之间的关系打下了基础。在开发过程中使用一系列成熟的基本构造块并运用一致的语言，能够使开发工作更加清晰而有条理。 我们面临的真正挑战是找到
3. 领域对象的生命周期 。 每个对象都有生命周期，如下图所示。对象自创建后，可能会经历各种不同的状态，直至最终消亡——要么存档，要么删除。当然很多对象是简单的临时对象，仅通过调用构造函数来创建
为了保证软件实践得简洁并且与模型保持一致，不管实际情况如何复杂，必须运用建模和设计的实践. 某些设计决策能够使模型和程序紧密结合在一起，互相促进对方的效用。这种结合要求我们注意每个元素的细节
大家好，我是 ddd 设计的新手，正在尝试使用这种在 C# 中工作的模式开发我的第一个应用程序 在我的应用程序中，我有一个包含子实体 Assets 的聚合合约，当添加或结算 Assets 时，我应该在
我正在尝试弄清楚如何使项目的一些消费者(业务客户)的不变量保持一致，他们对同一版本的聚合根有自己的要求。让我们以客户为例，提出假设性问题以满足以下愚蠢的逻辑: public class Custome
我见过一些具有实体值对象表示的 DDD 项目。它们通常显示为 EmployeeDetail、EmployeeDescriptor、EmployeeRecord 等。有时它包含实体 ID，有时不包含。
我试图了解如何表示某些 DDD(域驱动设计)规则。 遵循蓝皮书约定，我们有: 根实体具有全局身份并负责检查不变量。 根实体控制访问，并且不会被其内部结构的更改所蒙蔽。 对内部成员的 transient
我对 ddd 中的验证方法有疑问。我已经阅读了相当有争议的意见。有人说这应该在实体之外，其他人说这应该放在实体中。我试图找到一种我可以遵循的方法。 例如，假设我有带有电子邮件和密码的 User 实体。
寻找有关如何解决此问题的建议，并了解域驱动设计是否真的是这里的最佳模式。 我的客户正在重新构建其几近过时的工具和服务堆栈。客户是一个快速扩张的电子商户。它的核心产品是它的大型电子商务网站。围绕该网站，
我很难找出实现依赖于数据库中存储的数据的业务规则验证的最佳方法。在下面的简化示例中，我想确保用户名属性是唯一的。 public class User() { public int Id { g
情况: 要处理域事件，Jimmy Bogart proposed 一种将事件存储在聚合中的方法。 在我看来，这是一种非常方便的方法。但是，域服务中的域事件怎么办？ 域服务不应该有状态(stateles
我正在处理遗留项目，试图改进项目结构。我的问题是我应该如何组织代码结构。我看到两个选项: #1 business-domain / layer app/ ----accout/ --------app
根据 DDD 原则，所有处理与特定聚合根对象相关的实体的 CRUD 操作都应该由聚合根进行。 但是我们如何从 aggr 根中仅更改实体的单个属性？我们应该在实体中有 setter 方法吗？这些方法应该
我是一名优秀的程序员,十分优秀！