• DDD领域驱动设计与OO面向对象之间是有区别的,面向对象更注重抽象,从差异中寻找共同点,然后将其抽象出来;而DDD更注重上下文边界,这种边界代表区分差异。其实这是两种不同的思维方式。在
  • 上下文感知的英文是:Contextual Awareness;态势感知或称情境感知的英文是:Situational Awareness。情境Situational或事件发生在一个上下文中,这个上下文即与实际事件相关的周围事实。意识到一个事件有上下文被称为上下文感知/上下文意识(Con icon
  • 2002年,亚马逊的杰夫·贝佐斯发布了一份备忘录,该备忘录已成为技术行业经典。这份备忘录被称为“API Mandate”(API授权执行书),通常被视为亚马逊技术声明,因此受到技术人员的广泛钦佩,并被高管完全忽视。这很不幸,因为可以毫不夸张地说,API 3Mandate彻底改变了亚马逊作为一 icon
  • 假设有一个农业机械零件的批发商。他们建立了一个 B2B 网上商店,供经销商和机器维修公司订购。在他们无处不在的统一语言与术语中,订单代表了这个自动化流程:它使客户能够挑选产品,应用正确的折扣,并将其推送到 送货。如果这个批发商与竞争对手合并:他们是老牌企业,拥有稳固的客户群和庞大的目 icon
  • 领域驱动设计的主流思想是关于实体、值对象、聚合、存储库、服务、工厂……各种技术模式。因此,大多数人认为他们不需要领域驱动设计,因为这对他们的领域来说很复杂。为什么你需要所有这些“东西”?好吧,也许你不需要!在一个大型系统中,如果您正确使用存储库模式,建模您的领域、定义边界以及 icon
  • Webhook是“用户定义的 HTTP 回调”: 它们通常由某些事件触发(不是通常用用户操作人为触发的),例如将代码推送到存储库或发布到博客的评论; 当该事件发生时,源站点就向为 webhook 配置的 URL 发出 HTTP 请求。用户可以将它们配置为导致一个站点上 icon
  • 在前面帖子如何绘制Wardley地图?中,我们假设了一个SaaS 企业的创始人案例,为了挽救即将倒闭的公司,你需要进行理智的分析,理顺你公司的战略设计存在什么漏洞。这可 icon
  • 本文将面向对象分析设计的单一职责等#SOLID原则应用于微服务划分,以及DDD领域划分/上下文分界/DDD聚合等设计概念中,是一种实际中每天重复的设计习惯:松耦合和高内聚这两个术语似乎同时存在的:这两个概念是一起创造的,如果您谈论其中一个,通常也会出现另一 icon
  • 将大型复杂系统模块化为更小、更易于管理的部分是很好的最佳实践,不仅可以降低每个部分的认知负担,还可以实现团队独立性和操作弹性。棘手的一点是如何划定边界?为整个系统建立一个稳定和可持续的结构。基于有界上下文的领域驱动设计是一种方法,其中是使用领域语言作为指导,另一种方法是从业务模型定义 icon
  • 这是Oliver Human & Paul合著的何为复杂性?复杂系统只能仿真建模? - Cilliers的第 17 章——走向复杂的经济:定义复杂性的不是相互作 icon
  • 在分布式软件应用程序中,不同的服务或进程或应用程序经常需要相互通信。微服务和容器以及云原生应用程序的现代架构趋势都增加了应用程序将越来越多地部署为相关服务的集合而不是单个单体的可能性。这些应用程序可以通过多种不同的方式相互通信,每种选择都会带来一定的好处以及后果和权衡。让我们考虑选项并根据其 icon
  • 本文是作者pathelland二十年分布式经验分享,其中很多概念与DDD和有界上下文映射非常类似,只不过使用了fiefdom而不是domain来表达。本文介绍了一个称为fiefdom封地/领地(banq注:类似Domain)的概念 :这是一个自主计算和数据的集合,旨在与不受信任的外部 icon
  • Wardley Mapping是西蒙·沃德利创建的一套战略思维探索工具,点击标题是一款在线Wardley-Mapping绘制工具,用来实现DDD战略设计或产品 icon
  • 具有讽刺意味的是,强调无处不在的语言的 DDD 社区搞砸了这么多预先存在的DDD术语:DDD聚合Aggregate这个词语准确吗?“聚合”完​词语可能​全过载。DDD社区意见领袖mathias将其视为“确定性单位”,它是某些数据和规则的一致性边界,在此边界内,您具有原子性、无 icon
  • 您可以通过多种方式进行商业自杀,但可能没有比尝试伟大的架构目标(所有应用程序都与之对话的单一权威数据库)所产生的死亡更慢、更痛苦的死亡方式了。如果我们有一个单一的数据库,那么我们将所有的业务信息放在一个地方,所有人都可以访问,易于报告,降低维护成本,所有应用程序的一致性,以及许多其他 icon
  • 领域驱动设计是您应该了解的概念——无论您是开发人员还是领域专家。使用 DDD 处理复杂的软件项目。领域驱动设计 (DDD) 的概念是由 Eric Evans 提出的。早在 2004 年,他就在他的著作领域驱动设计(又名“蓝皮书”)中写到了这一点。 DD icon
  • 在 REST API 中使用布尔值坏处: 会阻碍API 可扩展性 会屏蔽和混淆域清晰度 会妨碍代码 可读性和可维护性 让我们深入研究这些领域并审核布尔值在 REST API 中的常用方式。 API 可扩展性 icon