DomainDriverDesignwithJava的中文翻译-学习过程中翻译的资源-CSDN文库

需积分: 8 168 浏览量 2022-12-27 10:56:31 上传评论收藏 36.71MB PDF 举报

资源推荐

资源详情

资源评论

前言

领域驱动设计（DDD）提供了一组原则、模式和技术，主题专家、架构师、开发人员和其他团队成员可以采用这

些原则、模式、技术来共同工作，并将复杂系统分解为良好的、协作的、松散耦合的子系统。当埃里克∙埃文斯

（EricEvans）在21世纪初引入这些概念时，在很多方面，这些原则都远远超前于他们的时代。我们坚定地站在

单一的时代，面向服务的架构（SOA）作为一个概念刚刚开始扎根，而云、微服务、持续交付等等甚至还不存

在！虽然采用某些战术方面相对容易，但DDD的战略方面在很大程度上仍然被视为不合理的开销

第一部分

尽管IT行业以处于技术的最前沿而自豪，但它也监管着相当高比例的项目，这些项目由于某种原因而彻底失败或

无法达到最初的目标。在第1部分中，我们将探讨软件项目未能实现其预期目标的原因，以及实践领域驱动设计

（DDD）如何显著提高实现成功的几率。我们将快速浏览埃里克∙埃文斯（EricEvans）在其同名开创性著作中阐

述的主要概念，并探讨其在分布式系统时代的重要性。我们还将研究几种流行的体系结构样式和编程范式，并探

讨DDD如何适应事物的方案。

太多的架构

编写复杂的软件是一项艰巨的任务。你不能只希望坐下来开始输入代码，尽管这种方法在一些小情况下可能有

效。在将业务想法转化为工作软件之前，必须彻底了解手头的问题。例如，如果不首先了解信用卡的工作原理，

就不可能（或者至少是极其困难的）构建信用卡软件。为了传达您对问题的理解，在编写代码之前创建问题的软

件模型并不罕见。此模型或模型集合表示对问题和解决方案架构的理解。

创建一个完美的问题模型的努力——一个在非常广泛的背景下准确的问题模型——与众所周知的圣杯追求并无不

同。负责构建体系结构的人可能会陷入分析瘫痪和/或前期的大设计中，产生一个或多个层次过高、一厢情愿、镀

金gold-plated、流行语驱动buzzword-driven或与现实世界脱节的工件，而无法解决任何实际业务问题。在项

目的早期阶段，当团队成员的知识水平仍在不断提高时，这种锁定尤其有害。不用说，采用这种方法的项目很难

始终如一地取得成功.

太少的架构

敏捷软件交付方法在90年代末和2000年代初表现出来，以应对被统称为瀑布的重量级过程。这些过程似乎倾向于

基于一厢情愿的理想世界场景的前期大设计和抽象的象牙塔思维，在项目进展过程中，提前想好事情的前提最终

会避免严重的开发难题。

相比之下，敏捷方法似乎更倾向于一种更灵活和迭代的软件开发方法，高度关注工作的软件而不是其他工件，如

文档。如今，大多数团队都声称要实践某种形式的迭代软件开发。然而，由于痴迷于宣称与底层原则相对应的一

系列特定的敏捷方法，许多团队误解了只有足够的架构而没有可感知的架构。这导致了一种情况，即添加新功能

或增强现有功能所需的时间比以前长得多，从而加速了解决方案的发展，成为令人恐惧的大泥球

额外的复杂度

MikeCohn普及了测试金字塔的概念，他在那里谈到了大量的单元测试应该如何形成一个健全的测试策略的基

础，随着你向金字塔的移动，数量会显著减少。这里的基本原理是，当你往金字塔上移动时，维护成本会大幅上

升，而执行速度则会减慢。然而，事实上，许多团队似乎采用了一种与完全相反的策略-测试冰淇淋筒，如下图所

示：

测试冰淇淋筒是FredBrooks在其开创性论文《软件工程中的无银弹本质和意外》中称之为偶然复杂性的经典案

例。所有软件都具有解决问题所固有的一些基本复杂性。在为非平凡问题创建解决方案时尤其如此。然而，偶然

或偶然的复杂性并非直接归因于问题本身，而是由所涉及的人员、他们的技能水平、所使用的工具和/或抽象的局

限性造成的。不关注偶然的复杂性会导致团队从关注真正的问题偏离方向，解决提供最大价值的问题。这样的团

队很自然地将成功的几率降到最低。

非受控技术债务

金融债务是指向外部方借款，以迅速为企业运营提供资金，并承诺及时偿还本金和约定利率。在适当的情况下，

这可以大大加快企业的发展，同时允许所有者保留所有权、减少税收和降低利率。另一方面，无法按时偿还债务

可能会对信用评级产生不利影响，导致利率升高、现金流困难和其他限制。

当开发团队采取可以说是次优的行动来加快一组特性或项目的交付时，技术债务就是结果。在一段时间内，就像

借钱可以让你更快地做事一样，技术债务可以导致短期的速度。然而，从长远来看，软件团队将不得不花费更多

的时间和精力来简单地管理复杂性，而不是考虑产生架构上合理的解决方案。这可能导致恶性循环，如下图所

示：

在麦肯锡最近的一项调查中，向首席信息官发出的报告中，约60%的人报告，过去3年技术债务的数量有所增加。

同时，超过90%的首席信息官将不到五分之一的技术预算用于支付高软件质量（或缺乏高软件质量）与可预测地

增强软件的能力之间的深度关联。虽然承担一定数量的技术债务是不可避免的，也是做生意的一部分，没有系统

地偿还债务的计划可能会对团队生产力和实现价值的能力产生重大不利影响。

忽略非功能性需求

剩余158页未读，继续阅读

内容反馈

nchwang

粉丝: 0
资源: 6

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈

feedback-tip