我们如何从DDD中受益？ 第三部分

DDD最大的挑战绝对是战略设计部分，即如何划分有界上下文正确和构建领域模型。

很难用语言表达清楚，我认为最好的方法是更多练习，并从大师那里学到更多东西，例如，尝试Event Storming。

之后，如果团队没有任何领域驱动开发经验，请不要低估技术部分的挑战。和很多人说技术部分不那么重要不同，如果没有以适当的方式实施，领域驱动很难真正理解。我们在练习时遇到了一些典型的问题，幸运的是，我们很好地解决了这些问题。

1. 开发人员认为Event Sourcing并不重要，例如，在之前案例情况下，您只需要在发布Job时更改属性Job.Status =“Published”，但现在需要定义了JobPublishedEvent。有时，一个更改需要定义很多事件，例如CompanyNameChangedEvent，CompanyEmployeeAddeedEvent。最重要的是，如何定义事件的粒度？
2. 由于系统被划分为大量基于有界上下文的子系统，系统之间的交互更加复杂。通过在以前的情况下在同一个MVC控制器Action中调用不同存储库的方式更改数据在此处不可用。
3. 由于在使用CQRS进行查询时需要单独存储QueryModel，因此与传统的数据库驱动开发相比，在同一数据库中的写入和读取更复杂。
4. 事件的版本管理，例如事件的更改，删除和增加都需要考虑事件重放和域模型引起的影响。
5. CQRS如何保证数据的及时性和一致性？例如，我在公司详细信息页面中更改了公司名称，然后单击了保存按钮以导航到公司列表页面，QueryModel可能仍未更新。

领域驱动设计如何使我们和我们的客户受益

1. 做正确的事：Domain Expert和团队之间的高效通信保证了正确反映业务规则的模型的设置。由于开发人员拥有可以直接使用的代码，以及因Domain而生成数据和行为，因此进行单元测试非常方便，因为Domain不依赖于第三方数据存储，这可确保业务的实施。
2. 它大大提高了通信效率。我们都知道，一张图表说的不止一千字。至于开发人员，他们真正需要的是“少说话，给我看代码！”。代码不仅更容易让开发人员阅读，而代码（Domain Object）也是最新的要求，即运行要求。
3. 它大大提高了为项目添加新资源的效率。当一个新资源被添加到项目中时，它主要需要检查域模型和测试域模型，然后您将通过此过程了解系统的几乎所有业务规则。
4. Domain-Driven的技术部分为添加新功能或扩展系统带来了极大的便利。我在这里举几个例子：

• 由于使用了事件源，我们很容易检查历史数据，也就是说，我们只需要分配一个时间点，然后我们只需要在我们做事件重播时重播到这个时间点。
•  操作日志：以前，如果我们想要记录操作日志，会有整个代码的日志，但是现在我们只需要重放事件，然后你可以检查你想要查看的任何日志，它可以通过重放事件流简单地实现数据库存储。
• 系统通信：通过事件发布可以实现通信，其他系统只需要订阅我们的事件，我们的系统和其他系统之间没有直接的依赖关系。
• 它大大提高了向系统添加新功能的便利性，在大多数情况下，它只是添加新功能时的事件订阅。
• 即 CQRS和Query模型大大提高了系统的查询性能。当我需要一个新接口时，我不需要对写入端进行任何修改，包括类文件。是否与关闭修改和开放扩展（OCP）的规则非常一致？我们只需要构建类似于新的EventHandler并重播相应事件的东西。
• 由于使用了事件源，系统之间的事件集成（如消息队列发布和事件订阅）可以大大提高系统压缩能力。我们可以将事件放在队列中，因此如果以后没有及时处理系统处理，它不会导致前端系统崩溃。
• 系统性能大大提高。写入端只有插入操作，没有修改操作; 并且在读取端只有读操作。结果，可以大大减轻输出存储和读取的瓶颈。

其他好处：

1. 开发人员可以更专注于解决业务问题。由于一切都是事件，开发人员可以在基本库实现后忽略数据存储，并将大部分时间花在编写业务代码上。如果不关心如何存储数据，那么数据存储只有两个操作：AggregateRoot.Get（ID），AggregateRoot.Save（）
2. EventPublish.Pubish（CompanyNameChangedEvent）然后事件订阅者只需要添加一个EventHandler。
3. 系统很好地解耦，业务逻辑集中在领域中，不同于以前在许多地方存在业务逻辑的情况，现在您在修改某些功能时不需要太担心。
4. 不需要过多担心开发人员，特别是由初级开发人员编写的遍布整个系统的错误代码导致的对其他功能的影响将大大降低。审核代码实际上是审核业务实现的单元类，因此不需要过多担心技术实现引起的不正确部分，因为开发成本可以通过基本库的适当平衡来减少团队成员写得很好。
5. 最后，更容易做出更改和添加新功能的好处，完全支持敏捷哲学的“拥抱变化”，是不是？

领域驱动设计有许多好处，许多概念，相对有较高的障碍和对人员有高要求。至少应该有团队中的领导者，否则，成本会很高，尤其要小心使用事件溯源。Domain-Driven特别适合那些业务相对复杂的项目，对于那些小项目，CRUD仍然是一个不错的选择。