限定上下文BC

EventStorming是一种非常流行的技术，它使我们比传统技术更有效地探索，分析和建模业务领域。由此我们可以创建与设计更好的软件系统和问题解决方案。明智地使用EventStorming，我们可以发现有关我们的域和业务的足够信息，以便我们可以使用它来设计微服务，有界上下文甚至我们的

ContextMapper是一个开源工具，提供基于领域驱动设计（DDD）模式的DSL，用于实现上下文映射和服务分解。Context Mapper项目是瑞士东部应用科学大学（HSR FHO）<

围绕一个系统的某个区域的活跃的领域知识才是有保存价值的基本单位，但是这容易被破坏隔离，领域的知识连续性很重要，DDD的有界上下文概念似乎是一个很好的基础。 (特性团队是跨专业的, 面向最终用户交付完整价值的团队，组件团队Component Team

Alberto Brandolini是EventStorming的发明者，一种在领域驱动设计环境中的研讨会格式，可让您快速了解软件领域的情况。Alberto Brandolini是EventStorming方法的发明者 - 这一概念将领域驱动设计（DDD）背后的论文转化为实践。他的书

您正在构建一个新系统，并且您的团队的两名成员各自提出了用于发送通知的两种架构，哪一个是正确？如何选择？ 第一个开发人员提出的是推送模型：有界上下文应指示通知上下文发送通知。专门的通知上下文应该只是遵循来自其他上下文的命令，并在指示时发送通知。 第二个开发人员不

时间和资源是有限的，在开发软件系统时，我们如何花费有限时间并利用有限资源解决最根本、最困难的挑战？在我们可能要做的所有事情中，我们应该做什么，我们应该投资多少质量和严格度？对于软件工程师来说，自然的趋势是倾向于迎接最有趣的“技术”挑战。尽管并非总是如此，但我可以从自己的亲身经历中确认

Event Storming是一种跨职能促进技术，用于揭示系统或业务流程的有界上下文，微服务，垂直切片，故障点和起点。建议时间：12小时。谁参加？中小企业，核心团队（见主持人说明） Event Storming可以将单块体分解为微服

领域驱动设计看起来真的很复杂，有很多行话，等等。总而言之，这是一种分而治之的方法。第一件事就是将您的业务划分为更小的“块”。每个块都易于处理+理解。但是，为了能够做到这一点并以有利于业务的方式，您需要了解......业务。这个业务的动态部分是什么？有哪些人参与？是谁？他们在做什么？他

在软件设计中，“越小越好”几乎普遍是坏建议，例如针对数据库分区，消息大小，μsvcs，有界上下文，类名，方法一致性等。一些关键业务逻辑会越过这些细粒度边界，并导致实施不当。小粒度事物看起来很简单，因为错误不是隐藏在事物内部，而是隐藏在它们的连接中。 事物边界会变大，很少变小或

很多时候，有界上下文中的统一语言被一些本不应该在那个位置的语言定义了（banq注：一些行业术语或行话其实具有误导性），这需要一个搜寻提取领域纯度的思考，需要正确的抽象才能实现。 众说纷纭：语言很重要，“根据挪威语言学家奥列·亨里克·马加（O

只有我发现使用foo和bar的编程示例极其无助且令人困惑吗？请写出真实的词，这可能有助于我解释“ foo”可能做什么的含义。 众说纷纭：我通常觉得foo / bar通常与假定的知识解释结合在一起。

构建微服务很容易，难点是：-找到微服务之间适当的界限-集成服务（消息传递与RPC）-错误处理（弹性）-Sociotechno社会技术的关注（团队划分界限，组织变更）  

“企业资源计划系统”（ERP系统）之类实际上是一种瑞士军刀软件系统。毫无疑问，它们确实是功能强大的工具，但是在某些情况下，它们可能造成的弊大于利。因此，我想讲一个虚构的故事，该故事显示了组织如何陷入困境。为此，我将尝试使用Nick Tune的全新

“单体与微服务”的争论通常集中在技术方面，而忽略了战略和团队动力。但是，思维敏捷的组织不是从技术入手，而是以团队的认知负担作为有效交付和运行现代软件系统的指导原则。 

如果在会计财务性质的行业进行建模，这是会有一个稳定的统一语言；如果在市场行业建模，他们会发明一些新的概念，从而破坏你设计好的模型。 banq: 需要将可变从不变的结构中分离出来，这也是使用事件溯源的优点。