如今，很多项目都关注于领域驱动设计，但事情并非总是那么容易。其中最重要的事情就是从只因技术原因而存在的代码中将领域代码分离出来。
Mats Helander 在 InfoQ 写了一篇文章，是关于如何用他称为领域模型管理的概念来设法处理领域模型。在文章中，Mats 引领读者一步步解决了在实现一个领域模型时涉及设计和关注点分离的普遍问题，解释了解决问题的方法，并传授了在这个过程中出现的面向方向编程、一对设计模式、以及关于对象 / 关系映射的一些知识。
在下面的文章摘录中，Mats 谈论了把基础架构代码放在哪里的问题：
随着基础架构代码的增长，找到一个处理它的优良架构变得越来越重要。问题主要在于——我们是否允许把一些基础架构代码放在我们的领域模型类里面，还是无论如何应该避免这样做？
避免基础架构代码进入领域模型类的论点是强有力的：领域模型应该表示应用程序所处理的核心业务概念。对于想大量使用其领域模型的应用来说，保持这些类干净、轻量级、易于维护是一个极好的架构目标。
另一方面，我们接下来将会看到，保持领域模型类完全不含基础架构代码——通常被称为使用 POJO/POCO（Plain Old Java/CLR Objects）领域模型，这种极端的路线也被证明是有问题的。最终往往导致采用笨重的、低效率的变通方法来解决问题——而且有些功能用这种方式根本不可能实现。
也就是说，我们遇到的还是一个权衡利弊的情况，我们应该尽量在领域模型类里面只放必不可少的基础架构代码，决不超出这个限度。我们付出领域模型的轻微发胖，换来效率的提高以及使一些必要领域模型管理功能有可能实现。毕竟，软件架构很大程度上是关于如何做一笔好买卖。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
超大规模集群下大语言模型训练的最佳实践
Shifu 如何赋能 IoT 应用开发
FastData DLink 实时湖仓引擎架构设计与落地实践
评论