DDD领域驱动设计

为了分析现有的业务流程，我使用了一种称为事件建模的技术。这种建模技术主要集中于识别在业务流程中发生的有意义的业务事件。一旦识别出这些事件，它们便构成了设计过程的基础，该设计过程导致了DDD，CQRS和ES中描述的一组处理模式得以实现。 事件建模是亚当·迪米特鲁克（Adam Dymitruk）创造的一

通常将软件的复杂性（无论是编程语言，API还是用户界面）视为坏事情。然而，实际上没有人会在一开始就构建复杂的东西，那么复杂性为什么会异常普遍存在呢？这对于希望构建易于使用的软件感兴趣的人，了解导致复杂性Complex的原因至关重要。幸运的是，我相信这里有一个简单的解释。 任何功能需求的最自然的实现都

这是阿尔贝托·布兰多利尼（Alberto Brandolini）的观点，他在[url= Storming中[/url]提出了这一点（他实际上是在谈论软件开发，但我不想就软件工程与开发之间的区别进行学术讨论，

众所周知，客户问题是所有产品开发的基础。然而，如果我们与开发人员或产品经理交谈，他们通常不太清楚需求。这里的问题在于术语，“需求”这个词里面有两个词的意思：客户需求和产品需求。要澄清这一点，必须理解一个高级概念：将问题空间与解决方案空间分离。 问题空间 一个市场是一组相关的客户需求，它完全位于问题空

幽默1：多亏了微服务，我们的JOINS(SQL语句)现在可以跨HTTP了。 banq评：SQL的JOIN是跨表操作，这种跨表操作可能会将本是松耦合的两个数据表耦合在一起，变成一个整体，相互绑架，无法各自独立扩展。如果使用DDD的有界上下文设计微服务，清晰划分好微服务的边界，微服务之间如果需要通讯，通

在这里，我将揭开“涌现Emergence”的神秘面纱，并将其完全具体化。 大多数人都将其视为哲学家和神秘主义者的一种模糊概念。 如果您尝试阅读有关涌现Emergence的维基百科，您会和我一样反应：“天哪！太难懂了” 我

现代企业架构师工具套件： [list] [*]-Wardley Mapping（业务-> IT产品组合） [*]-使用[url= (康威定律) [*]-战略性领域驱动设计 [*]-实时文档记录（[ur

为什么推荐在创业公司中使用#eventsourcing、#dddesign和#microservices微服务？ 在过去的一年中，我参加了很多有关eventsourcing事件溯源的网络研讨会，讲座和讲习班。很多时候观众回答一个问题：什么时候使用这种模式？也就是说：在什么情况下，事

领域驱动设计（DDD）最近变得越来越流行，新书，会议演讲（甚至是专门针对它的完整会议）以及许多培训，从模式语言的最佳意义上讲，DDD为许多开发人员和设计人员在如何设计这件事情上给出了一个明确的名称，过去他们是无法可靠地、兼容地进行沟通。 但是，我对最近的事实也感到恼火，似乎每当有人谈论如何设计系统或

本文是关于我在使用ASP.NET Core和EF Core的小型但复杂的应用程序上使用模块化单体/整体结构和域驱动设计（DDD）方法的经验。这不是有关模块化单体架构或DDD的入门知识（但每个链接都有很好的摘要），但我对每种方法的优缺点都有自己的看法。 主要心得： 模块化Monolith单体体系结构是

这篇文章使用一个简单的示例说明了域建模过程。第一步，确定实际问题。接下来，找到一种解决方法。接下来是创建初始域模型。之后，提供第一实施方式。然后，讨论并解决了技术和逻辑上的挑战。此外，还将解释域模型及其实现之间的差异。该帖子最后建议即使对于小型项目，也应使用以问题为中心和模型驱动的方法。 问题识别

能够满足用户需求的优秀软件的关键是什么？对我来说，它不是编程语言或框架。它是对业务域以及系统如何在用户上下文中工作的深刻理解。工程学科可以为我们提供帮助。 持续交付。当软件始终处于可发布状态时，我们可以经常将其交付给用户以获取新知识。 领域驱动设计。DDD使我们能够构建一个由团队，业务甚至源代码共享

2021年的DDD将是什么样？ [list=1] [*]可视化协作领域建模 [*]领域驱动的架构设计（战略性DDD） [*]领域驱动的软件设计（战术性DDD） [*]DDD主义 [/list] [img]

[img] 您在图片中看到了什么？一块硬纸板？一些垃圾？ 不是！这是模型！ 它是西门子KG86NAI31L冰箱的模型。纸板看起来不像冰箱吗？—是的，但并不重要。模型不是真

领域驱动设计是一种设计系统（通常是软件）的方法，该方法强调在域专家和系统构建者之间创建通用语言。著名的DDD原则包括使用[url=