• Cynefin框架是一个概念性框架用于辅助决策,由戴夫·斯诺登在IBM全球服务部工作时于1999年创建。它是马克斯·博伊索特的I-Space知识模型一种实现,其他实现还有用于DDD战略设计的 icon
  • 本文是复杂性领域权威著作保罗·西利亚斯(Paul Cilliers)的《至关重要的复杂性》摘录,入门人工智能或DDD建模必读书籍! 在一个不确定非线性世界中,我们无法追踪清晰的因果链,现在看来似乎不重要的事情可能在以后变得至关重要,如蝴蝶效应。我们的模型必须以某种方式“构架”问题,而这种构架却不可避 icon
  • 当您公司的整体Web应用变得太大而脆弱时,部署变得缓慢而令人恐惧。因此,作为一家软件公司,您已决定遵循许多其他公司所采用的方法——将这个整体/单体架构拆分为微服务架构。 这个迁移旅程可能 icon
  • 假设有一个农业机械零件的批发商。他们建立了一个 B2B 网上商店,供经销商和机器维修公司订购。在他们无处不在的统一语言与术语中,订单代表了这个自动化流程:它使客户能够挑选产品,应用正确的折扣,并将其推送到 送货。 icon
  • 例如,假设您是一家 SaaS 企业的创始人/首席执行官,其主要产品是一个 Web 应用程序,可让用户存储和操作他们的照片。您正在查看第二季度的收益,并意识到您目前的收入流可能还剩下六个月的运营费用。 在过去的五年中,您以直觉和最佳实践相结合的方 icon
  • 领域驱动设计的主流思想是关于实体、值对象、聚合、存储库、服务、工厂……各种技术模式。因此,大多数人认为他们不需要领域驱动设计,因为这对他们的领域来说很复杂。 为什么你需要所有这些“东西”?好吧,也许你不需要! 在一个大型系统中,如果您正确使用存储库模式,建模您的 icon
  • 在前面帖子如何绘制Wardley地图?中,我们假设了一个SaaS 企业的创始人案例,为了挽救即将倒闭的公司,你需要进行理智的分析,理顺你公司的战略设计存在什么漏洞。这可以通过Wardley 地图实现,绘制该地图的难点是:将公司的能力置于正确的演进阶X轴 icon
  • 相关性不代表因果关系,但是没有相关肯定没有因果吗?诺贝尔奖获得者卡尼曼也有范常识错误的时候: 《思考,快和慢》是由诺贝尔经济学奖获得者丹尼尔·卡尼曼(Daniel Kahneman)于2011年出版的畅销书。 主要论点是两种思维方式: “系统1”是快速,本能和情感的; “系统2”更慢,更仔细,更合乎 icon
  • 将大型复杂系统模块化为更小、更易于管理的部分是很好的最佳实践,不仅可以降低每个部分的认知负担,还可以实现团队独立性和操作弹性。 棘手的一点是如何划定边界?为整个系统建立一个稳定和可持续的结构。基于有界上下文的领域驱动设计是一种方法,其中是使用领域语言作为指导,另一种方法是从业务模型定义的能力中汲取灵 icon
  • 一旦您拥有多个微服务,就很难在一张图上显示所有微服务。建模方式有几个选项: (1)对图进行分区:显示每个单个的领域,有界上下文映射/业务能力等是一种很好的方法。 (2)也可以集中于单个微服务及其传入/传出耦合。例如: icon
  • 用户故事映射通过一步一步的流程直观地显示用户浏览我们软件的过程,并在此过程中创建各种用户故事。与简单的积压订单相比,用户故事图在产品环境中增加了位置和移动的维度,使您可以先进行图绘制,然后浏览产品的整个用户空间。借助用户故事图,您可以在上下文中看到整个图景,而线性积压则不会那么多。 我们通过讲述用户 icon
  • 当业务流程跨多个系统流动时,集成要求对于任何项目的成功都是至关重要的。作为业务分析师,我们有责任了解端到端的业务和系统流程,并在需求收集流程中记录下移交。收集系统之间集成需求的系统方法将确保系统之间以及业务流程之间的平滑交互。下面的“集成需求分析框架”提供了一种系统的方法来记录集成项目的需求。 信息 icon
  • 认知神经科学的渐进模板: [list] [*]这是一个系统 [*]这是两个系统 [*]两个系统实际上是一个系统 [*]有两个但它们广泛地且动态地交互作用 [*]我们不知道运作方式 [/list] DDD建模认知的渐进模板: [list] [*]这 icon
  • 在 REST API 中使用布尔值坏处: 会阻碍API 可扩展性 会屏蔽和混淆域清晰度 会妨碍代码 可读性和可维护性 让我们深入研究这些领域并审核布尔值在 REST API 中的常用方式。 API 可扩展性 一个可扩展的 API应该让未来的变化显而易见并且易于实施。它不应引入复杂性或不必要的重 icon
  • 开发人员喜欢使用首字母缩写词来说明“良好做法”(KISS,DRY,SOLID等)。通常,他们传达的想法非常容易掌握。 DRY是dont-repeat-yourself不要重复自己意思,其目的是更好地管理复杂性,但是通过以这种基本/教条的方式应用DRY,我们发现复杂性有所增加。 DRY原则被陈述为“每 icon
  • 您如何构成一个DDD聚合?对我而言,聚合设计涉及对不变性的理解。不变是必须始终保持一致的业务规则。了解不变式将指导您的聚合设计。聚合是基于不变性和一致性定义边界的另一个示例。 送货案例 我将使用的示例是“Shipment”的概念。您可以将其视为送餐服务。您有在餐馆拿到的食物,然后送到家中。送货有2个 icon