第 2 章 发现领域知识 发现领域知识
本作品已使用人工智能进行翻译。欢迎您提供反馈和意见:translation-feedback@oreilly.com
在生产中发布的是开发人员的(错误)理解,而不是领域专家的知识。
阿尔贝托-布兰德里尼
在上一章中,我们开始探索业务领域。你学会了如何确定公司的业务领域或活动领域,并分析公司在这些领域的竞争战略,即公司业务子领域的边界和类型。
本章继续讨论业务域分析的主题,但从另一个维度:深度进行分析。它侧重于子域内部发生的事情:其业务功能和逻辑。您将学习用于有效沟通和知识共享的领域驱动设计工具:无处不在的语言。在这里,我们将使用它来学习复杂的业务领域。在本书的后半部分,我们将用它来建模并在软件中实现其业务逻辑。
业务问题
我们正在构建的软件系统是 业务问题的解决方案。在这种情况下,"问题"一词并不像一个数学问题或一个谜语,你可以解决它就完事了。在业务领域中,"问题 "具有更广泛的含义。业务问题可以是与优化工作流和流程、最大限度减少人工、管理资源、支持决策、管理数据等相关的挑战。
业务问题既出现在业务领域层面,也出现在子领域层面。公司的目标是为客户的问题提供解决方案。回到第 1 章中联邦快递(FedEx)的例子,该公司的客户需要在有限的时间内运送包裹,因此它优化了运送流程。
子域是粒度更细的问题域,其目标 是为特定业务能力提供解决方案。知识管理子域可优化信息的存储和检索过程。结算子域可优化金融交易的执行过程。会计子域负责跟踪公司的资金情况。
知识发现
要设计出有效的软件解决方案,我们必须至少掌握 业务领域的基本知识。正如我们在第 1 章中所讨论的,这些知识属于领域专家:他们的工作就是专门研究和理解业务领域中所有错综复杂的问题。我们绝不应该,也不可能成为领域专家。尽管如此,理解领域专家并使用与他们相同的业务术语对我们来说至关重要。
要使软件有效,就必须模仿领域专家思考问题的方式--他们的心智模型。如果不了解业务问题和需求背后的推理,我们的解决方案将仅限于将业务需求 "翻译 "成源代码。如果需求遗漏了一个关键的边缘案例怎么办?或者没有描述业务概念,从而限制了我们实现支持未来需求的模型的能力?
正如 Alberto Brandolini1 所说,软件开发是一个学习过程,工作代码只是副作用。软件项目的成功取决于领域专家和软件工程师之间知识共享的有效性。我们必须了解问题,才能解决问题。
领域专家和软件工程师之间有效的知识共享需要有效的沟通。让我们来看看软件项目中有效沟通的常见障碍。
交流
可以说,几乎所有的软件项目都需要不同角色的利益相关者的协作:领域专家、产品负责人、工程师、用户界面和用户体验设计师、项目经理、测试人员、分析师等。在任何合作中,结果都取决于所有各方的合作情况。例如,所有利益相关者是否都同意要解决什么问题?对于他们正在构建的解决方案,他们是否对其功能和非功能需求持有任何相互冲突的假设?在所有与项目相关的问题上达成一致和协调对于项目的成功至关重要。
对软件项目失败原因的研究表明,有效沟通对知识共享和项目成功至关重要。2然而,尽管有效沟通很重要,但在软件项目中却很少见到。通常情况下,业务人员和工程师之间没有直接的互动。相反,领域知识是由领域专家传递给工程师的。这些知识是通过扮演中介或 "翻译 "角色的人、系统/业务分析师、产品负责人和项目经理传递的。图 2-1 展示了这种常见的知识共享流程。
图 2-1. 软件项目中的知识共享流程
在传统的软件开发生命周期中,领域知识被 "翻译 "成一种 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access