介绍
域层是实体对象和相关业务逻辑的集合，旨在代表企业业务模型 。 该层的主要范围是创建一组标准化的 联合对象，可以在不同项目中重用这些对象。 一旦确定了对项目有用的企业业务模型部分 ，就必须启动分析模型设计的三个阶段 。
为了实现良好的域层设计，最好在分析过程中涉及以下角色：
- 带来业务知识的业务领域专家
- 研究领域并提供第一个建模的业务分析师
- 帮助防止在设计阶段可能出现的设计问题的业务架构师
主要设计原则
我想把重点放在三个设计原则上：
- 使用设计标准
- 设计不可知实体
- 远离技术细节
使用设计标准
设计标准使使项目看起来像参与开发和维护的IT人员一样是唯一的实体。 不使用设计标准就像开始用英语写一本书，然后用意大利语继续写中文一样。 对于大多数读者来说，它是不可读的。 由于领域是设计的第一层，因此应在此阶段定义设计标准，并且必须委托一个数字作为保管人。 最终，应用于企业的设计标准提高了互操作性 ，从而减少了集成工作量 。
设计不可知实体
域实体不与任何流程定义耦合。 因此，它们本质上是不可知的，并且具有潜在的可重用性 。 潜在的含义是必须付出一定的努力才能使他们有机会被真正重用。 当我们告诉您域层的范围是创建从企业业务模型建模的联邦域对象集时，从整体上考虑企业建模是不现实的。 在大多数情况下，一个项目只需要使用一小部分，因此建模将只专注于该部分。 这使得实现可重用性变得更加复杂。 在这种情况下，仅将注意力集中在特定项目感兴趣的业务对象的那些方面就很容易，从而为那些对象重用提供了机会。 投机性或更深入的分析可以帮助更好地了解其他过程如何查看和使用这些对象。 最后，在为业务模型的新部分建模之前，最好调查一下其他项目是否已经可以提供它（好吧，如果可以肯定地设计得很好！）。
远离技术细节
技术是IT的一部分，永远不会成为业务模型的一部分！ 但是，将技术概念放入域层仍然是一个常见错误。
例如，数据库只是域实体的持久表示模型 ，域实体不存在，因为它是数据库表的ORM！ 诸如JPA或Hibernate之类的库应从域层中排除。 如果您了解域层代表业务模型，那么您将接受ORM是基于该层构建的用于项目范围的顶层。 通常绑定到域的其他类型的技术是UI技术，一般的数据持久性和供应商平台。
领域层分类
在域层内部，可以根据对象的设计时间特征对其进行分类：
- 域实体
- 域服务
- 域逻辑
域实体
它全部涉及建模的业务对象，属性及其关系。
域服务
它定义了可以在同一层或不同层中实现的服务。 这为某些功能（如日志记录和异常处理）提供了一种抽象，可以根据将使用域层的环境对它们进行不同的管理。
域逻辑
与业务对象链接的逻辑的实现，例如验证规则，工厂和存储库。
域驱动设计
本主题的一小部分致力于域驱动设计 。 在本文中，我仅作为一种出色的设计哲学进行介绍，可以在设计域层时使用它。 以我的经验，它可以帮助我完全重构域层，并在很短的时间内增加投资回报率。
如何处理疑难案件
为了使这篇文章更有趣，我将介绍一个更常见的场景，并给出经验的回报。
到目前为止，所讨论的内容非常适合存在业务文档且业务流程清晰且稳定的情况。 正如你们许多人所经历的那样，情况并非总是如此……！ 缺少文档，缺少设计标准，不是IT文化，不希望共享知识的人们只是可能对完成一个完善的域（当然还有其他）层产生负面影响的一些问题。 那么，在这种情况下该怎么办？ 当我们在域层思考时，我们想像一下一块重石头，它不会轻易从其位置移动，那么如果它看起来更像是在风的控制下的叶子，该如何处理呢？ 如果截止日期很短？ 短期内是否还要关注质量？ 不要惊慌，这里有两个有用的提示。
为了确保自上而下的方法不可行，可以将敏捷和自上而下的方法更好地结合在一起，以实现快速发布并获得良好的质量回报。 当然可以DDD！
公司中的IT人员将永远不会替换领域专家，因此请勿尝试编写缺少的领域业务文档！ 相反，应专注于所有IT文档，并尝试帮助领域专家找到编写其文档的最佳方法，使他们了解这些文档是决定项目成功的最重要因素。
结论
精心设计的领域层至关重要，因为所有业务逻辑都将与之耦合，并且无论发生任何变化都可能产生重大影响。 自上而下的方法和前期的分析是设计它的首选方法。 在公司中存在无法抵抗轻易获得所需知识以完全完成任务的抵抗力时，最严峻的挑战可能会诞生。 在这种情况下，减少这些保留的一种方法是让业务专家与IT团队一起尽可能多地参与分析阶段。
翻译自: https://www.javacodegeeks.com/2013/05/multilayered-architecture-2-the-domain-layer.html
1301
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
