在JPA开发团队中，我们以领域驱动设计为参考来解决一些复杂的开发项目。因为我们的错误，但最重要的是，本文回答了一些同事的诚实问题以及其他人的疑问反对，我们一直在完善。在本文中，我将提出一些结论和实践，以帮助您遵循其原则。
最重要的是领域
首先从DDD引起我注意的是用于实施模型的推荐设计模式集：值对象，实体，服务，工厂，存储库等。模式是具有悠久传统并在行业中得到整合的工具（GOF，Martin Fowler，Eric Freeman等）。以前的经验使我认为这些模式正是DDD的最大贡献，但是我错了。
与DDD真正相关的是，强烈要求将Domain作为软件开发的真实来源。每当您认为自己偏离正确的道路时，都必须回到原点。例如，当您不确定要开发的功能的价值时，或者怀疑使用大炮杀死苍蝇时（过度设计）。有必要学习使该域始终可见，并质疑不适合该域的所有事物的价值。
“对任何领域未涵盖的开发提出质疑是领域驱动设计的主要课程”
我们如何指定领域？
通过模型指定领域。模型是一组工件（图表，文档，原型等），其中包含域的有意义的表示形式。这是业务掌握和技术设计之间的中间步骤。特点：
- 无处不在统一语言（“通用语言”）。对于业务和技术，它必须是可理解的且有意义的。所有团队成员（包括业务人员）在其交流中都使用模型的术语：用户故事，用例，功能，任务等。
- 它们是软件设计的基础和一面镜子。开发团队使用该模型来创建实现该模型的设计。而且，它将在项目的整个生命周期内使设计和模型保持同步。设计中的任何更改都必须根据模型进行验证。如果由于开发而认为必须对模型进行调整，则需要与业务部门一起审查变更并以通用语言执行变更。
当我们进入DDD时，第2点是需要更多的精力去适应和集中精力的点。保持模型和设计同步非常昂贵。正是这一成本，使您更加仔细地评估开发变更。可怕的结果是：“ 好吧，因为我是…… ”。权衡变更价值对成本的贡献就成为一项持续的工作。
模型的阐述
在DDD中，模型将通过两种力量诞生和发展：业务与开发。两种观点都必须从一开始就参与其创建。开发团队应该将模型视为工作的另一产品，理解模型如何帮助您创建更好的解决方案，并为模型的质量和代码的质量感到自豪。
将模型的创建或维护委派给团队外部的分析师根本行不通。团队必须在没有中介的情况下参与领域分析和建模的认知工作。这是维持敏捷过程并确保团队参与其维护的唯一方法。
建模工具
我已经是这个行业的资深人士。我经历了像RUP这样繁重的过程。系统地使用建模工件在阶段之间进行通信。当我担任业务分析师或设计师时，我广泛使用UML和BPMN。后来，在所有敏捷运动（尤其是XP）中，我都避免使用这些工具，其原则是代码应该是不言自明的。一如既往，保持平衡是美德。
建模工具（尤其是UML）对于为所有参与者建立有意义的框架非常有用。企业很难理解该代码。甚至使用专门改编的框架使它们更具表现力，例如“ 领域特定语言”。
代码对于设计而言可能就足够了。按照模块和组件进行组织，分配职责的一致策略以及统一的命名惯例应使设计显而易见。
您可以依靠具有许多IDE的代码分析工具来创建带有软件中存在的实体和依赖关系的图。这有助于理解设计并针对模型进行验证。分析图具有短暂的优势，我们无需花费过多成本即可创建和丢弃它们，因此我们不必对其进行管理。没有设计文档会阻止它取代代码所反映的事实。
使用UML时要小心。这是一个非常通用的工具。模型绝不应包含诸如继承，封装或特定类型之类的细节。我之所以这么说并不是因为模型必须与实现技术无关（我们很少在项目中寻找它），而是因为它失去了设计的中间步骤的作用。请记住，它是用于与业务进行交流并指导开发的抽象。
不断避免在模型上编写设计细节确实是一个苦难。但这正是DDD的目标。强制所有对话者使用与普遍存在的语言兼容的抽象级别。
模型管理
我与喜欢手工创建模型（带有标记）的同事一起工作。主要论点是，它们以始终“正在建设中”的脚手架之类工件反映了企业不断变化的性质。
对我来说很麻烦。如果我们使用黑板，则会不小心将其擦掉。如果我们使用纸张，则纸张会很快被圈圈图填充，并且清洁所花的时间要多于制造时间。在这两种情况下，信息都难以共享。
我更喜欢数字格式。我使用了诸如Visual Paradigm或ArgoUM L之类的专用工具。我知道它们给我的一切以及我剩下的一切。这就是为什么在许多情况下，我更喜欢使用较轻的工具来键入图表的原因。Draw.io非常适合中小型项目。但是，我一直在审查可用的工具。如果您使用的是最适合自己的产品，请在评论中注明。
结论：观看模型
域驱动设计是一种涉及从业务到模型以及从模型到软件的两种转换的技术。
模型在确保软件与其必须代表的业务之间的对应关系中起着核心作用。该模型必须始终存在于多学科团队的思想，计算机和黑板上。我们寻求一种“模型警察”的心态，以追寻与此通信一致性的任何偏差。