认识达内从这里开始

我们在前几期的文章中给大家介绍了领域驱动设计都需要掌握的一些基础知识等内容，而本文我们就继续来学习一下，领域驱动设计应用实践常见问题都有哪些。

实体：Entity，不同于通过属性进行定义的传统对象，实体对象通过标识进行区分，且具有持续的生命周期。

值对象：ValueObject，值对象是具有属性且不可变的对象，但没有标识。

领域事件：DomainEvent，领域事件用于记录系统内的模型活动相关的离散事件，虽然系统内所有事件都应该能够被跟踪，但只有被领域关心的事件类型才创建领域事件。

聚合：Aggregate，聚合对象是实体和值对象的聚合，聚合具有一个的根，即聚合根。外部对象不再直接访问聚合内部的单个对象或者实体，而是直接访问聚合根，并使用聚合根将指令传递给对应的分组。

领域服务：DomainService，某些领域逻辑不适合分配给某个特定的实体对象，可将其这些操作封装成领域服务

资源库：Repositories，资源库不是配置库，它提供一个全局接口来访问特定聚合内部所有的实体类和值对象，应该包括创建，修改，删除聚合内部对象的方法。

工厂：Factories，工厂封装了创建复杂对象和聚合的逻辑，对客户端屏蔽创建的复杂性

上述DDD战术设计的模式标识了进行设计时的一些关键模式，但并非说是一定要严格使用和遵循的，也不是遵循了所有的战术设计模式就是符合领域驱动设计。因为，实践DDD关键不在于这种战术层面模式的落地，而是在于其宏观的领域驱动设计思想的遵循，比如统一语言、领域模型与代码间的一致、子域及上下文的拆分以及映射、领域模型与技术关注点的分离等等。另外，随着DDD的不断发展，一些新的构建模式已经涌现，老的构造模型不一定能符合团队研发的要求。

领域驱动设计为什么落地这么难?

需要鲁棒的领域知识，依靠项目中领域的支持

如果团队中没有熟悉应用所需领域知识的领域，即使具备技术再强的开发人员也无济于事。在某些情形下，领域驱动设计需要一个或多个外部人员在整个软件开发生命周期中扮演领域的角色。有些情况下，领域驱动设计需要在整个软件开发生命周期中与外部团队成员(充当领域角色)进行协作。

在创新型业务中应用DDD同样存在挑战，由于业务模式的不确定性，业务需求变化的频率和幅度很大，同样也缺乏新领域的领域，整个业务都处于一种探索模式，很难建立起相对稳定、高可复用的领域模型。

强调不断迭代和持续集成，对缺乏迭代经验而偏重于瀑布模型的团队可能导致障碍

领域驱动设计实践依赖不断迭代和持续集成来构建高可扩展的项目，但是这种基于迭代和持续集成的时间，在某些团队中落地可能会存在阻碍，特别是如果过去经验是建立在僵化的开发模型上，比如瀑布模型。

不适合偏向技术型的应用

领域驱动设计适合于具有非常高领域复杂性(业务逻辑复杂)的应用，但不适用于领域复杂性很低但技术复杂性很高的领域。DDD着重强调需要领域以便构造出项目依赖的统一语言和领域模型，但是如果项目的技术复杂性很高，领域能否理解是一种挑战。当全体团队成员没有完全理解技术需求或限制时可能会导致问题

团队过于重视战术设计，导致实践准线和原则的偏离

团队对领域驱动设计的认知不够，精力没有聚焦在问题域拆分、统一语言、模型与技术关注点分离等核心原则上，而是一开始便从实现的角度触发，过度强调战术设计模式的落地，从而陷入无尽的技术细节之中

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。