一种领域驱动设计（DDD）方法在Laravel Framework中的实践

Laravel是一个健壮的框架，过去两年我一直使用它。直到今年初，它标准的架构对于我参与过的工程来说是足够的。

然而现在来了一个新的挑战，对于新的工程我们并不知道工程规模有多大，但是我们都知道工程应该根据情况需要尽可能的进行扩展，而且它对于新的团队成员来说应该是不难接受的，而未来可能会把应用的每个模块转换成微服务。所以我开始学习软件架构模式并选择领域驱动设计（DDD）。

关于DDD

DDD包含了一个持续改进场景的实现，可以作为一个极其有用的工具来开发高质量的软件来满足用户的需求。这个软件模式是由Eric Evans创造的。根据20年的面向对象技术的开发经验，他写了一本这方面模式的书。这个架构模式的焦点是领域，所以为了使软件完美的符合特定领域，有必要创建一门语言。在这门语言中，有很多术语是业务专家和开发团队日常交流的一部分。

为了保持聚焦于领域，我们需要把领域模型从系统其它部分隔离出来。实现这块的一个途径是分层架构：

• UI（用户界面）：负责给用户展示信息和接收新的数据。在现在或者未来，它的实现方式包括Web、控制台或者其它展现技术；
• 应用层：这一层没有业务逻辑，它是很功能单一的一层，负责连接用户层和其它更低的层。
• 领域层：展现的概念、规则和业务逻辑。整个DDD聚焦点都在这一层。负责把和其它系统进行通信，持久化详细信息等操作转发到基础设施层。
• 基础设施层：给其它层提供结构化的资源。它们通常是系统化的一部分，负责持久化数据，连接数据库，通过网络发送信息。

一个领域，也被称为上下文或者主题，不一定是一个实体。

可以将领域理解为应用知识领域。例如，在一个博客应用中，我们把博客看作一个领域，在它里面，我们会有一些和帖子进行交互的业务规则，像资源仓库、模型、服务等等。帖子，评论和分类是博客内部模型的示例。

标示领域的一个技巧就是与多个实体进行交互。

在了解我们的DDD方法前，你有两件事情需要了解：

• Laravel/Laravel是属于你的，它提供了标准的骨架但你可以修改它，以最佳的方式满足你的需要。不要和供应商的Laravel/framework混淆。
• 没有所谓“标准”的DDD方法，它是一个不断改进的过程，你将不断学习和适应它。

 

我们的DDD方法

在开始使用该方法时，要记住一点，我们不是和框架“打架”，因此我们所有的修改都考虑到下一个版本升级的便利性，但也会尝试把框架的优点融入我们的领域中。

在我写下这篇文章的时候，我们Laravel工程结构是这样的：

现在，你觉得这个应用容易维护吗？我觉得容易维护，理由如下：

• 如果X领域出bug了，改X领域就好了
• 如果Y有新功能需要添加，改Y领域好了
• 一个新开发人员负责Z领域，那么在Z领域开发好了
• W领域解构放到微服务里面？那么就把它挪出来放进去

 

总结

正如我之前所说，没有标准的途径来定义DDD结构，在学习了这个模式之后我们就是使用文章所示的工程结构。但是它是持续的过程，你需要不断改进来达到最好的效果。