Loading AI tools
来自维基百科,自由的百科全书
领域驱动设计(英语:domain-driven design,缩写 DDD)是软体程式码的结构及语言(类别名称、类别方法、类别变数)需符合业务领域中的习惯用法。例如处理租赁业务的软体,其型别可以命名为LoanApplication及Customer,其方法可以用AcceptOffer及Withdraw。
此条目需要补充更多来源。 (2020年3月23日) |
领域驱动设计的前提是:
该词是由埃里克・埃文斯(Eric Evans)在其同名书中创造。[2]
模型中有以下概念:
此条目翻译品质不佳,原文在en:Domain-driven design。 |
理想情况下,只有一个统一的模型。 但是通常情况下都无法实现,因此在实践中通常分成多个模型。 认识这个事实并遵守它对实践是非常有益的。 策略设计的目的是设计一套原则用于是维护模型完整性,提升领域模型和使用多个模型。
任何大型项目都有多个模型。 然而,当基于不同模型的代码相结合,软件变得越来越多,不可靠,并且难以理解。 团队成员之间的交流变得越来越难。 模型的使用情境变得越来越不清晰。
因此:需要明确定义模型适用的上下文,并且根据团队组织,应用程序特定部分的使用情况以及代码库和数据库模式等物理表现明确设置边界。 保持模型在这些范围内严格一致,并且不被外部的问题影响。
当愈多人在相同的有限背景下工作时,模型就愈应该分裂。 团队越大,问题就越大,即使只有三四个人也会遇到严重的问题。 然而,将系统分解为更小的环境最终会失去一个有价值的整合和一致性。
因此:建立一个经常合并所有代码和其他实现工件的过程,用自动化测试快速标记碎片。通过持续地运用统一术语去夯实随着概念在不同人的头脑中的演变而逐渐形成对模型的共同观点。
在缺乏全局认识的情况下,个别有界上下文会留下一些问题。 其他模型的背景可能仍然是模糊不清的。 其他团队的人不会意识到上下文的界限,并且会不知不觉地做出模糊边缘或使连接复杂化的变化。 当连接必须在不同的上下文之间进行时,它们往往会相互渗透。
因此:确定项目中正在使用的每个模型并定义其有界的上下文。 这包括非面向对象子系统的隐式模型。 命名每个有界的上下文,并将其命名为通用语言的一部分。 描述模型之间的关联点,确保任何用于共享交流的词语都有清晰明确的含义。 映射现有的情形。
在领域驱动设计一书中[2]阐述了一些高层次的概念和实践,比如通用语言,这意味着领域模型应该形成领域专家为描述系统需求而提供的共同语言,同样的,这些语言也需要能够被商业用户或赞助商和软件开发商使用。本书专注于将领域层描述为具有多层体系结构的面向对象系统中的常见层次之一。在 DDD 中,有表示,创建和检索域模型的工件:
为了帮助保证模型能作为一个单纯并有用的语言结构,团队通常必须在领域模型中实现大量的隔离和封装。因此,基于领域驱动设计的系统可能会花费相对较高的成本。虽然域驱动设计提供了许多技术优势,如可维护性,但 Microsoft 建议仅将它应用于复杂领域中,在这些复杂领域中,通过模型和语言处理能够在复杂信息中提供交流便利性的,并且能够该领域达成共识。[3]
采用 DDD 并不依赖于特定的工具。然而,也有许多开源的工具和框架可用,包括:
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.