C#程序员都要明白的，三层架构用的好好的，为什么要学DDD？

大家好，我是编程乐趣。

今天不推荐开源项目，我们今天来聊聊为什么有DDD这个东西。

因为我在星球里有写DDD的教程，所以也有很多学员就是冲着这个教程加入星球的。

但其实有很多开发人员，不明白为什么要学习DDD。

其实对于我们程序员来说，不明白为什么学这个技术、学这个技术能解决什么问题，是非常致命的。

你不知道为什么而学习，是非常可怕的，也往往学不好。

很多人说是因为DDD现在流行，所以要学习。虽然不能说这样的想法错了，但就因为流行才学习，很多人是会学不明白的，而且学完也不知道如何去运用。

下面我们聊聊三层架构与DDD的区别。

首先是三层架构，这个大家都很熟悉，就是把系统分为：表示层、业务层、数据访问层，为什么要这样分层呢？

相信大家都很了解，每一个层职责和功能是不一样的，表示层是负责前端的展示、业务层负责处理我们核心业务、数据访问层只负责与数据库打交道不涉及业务，在这里体现了“高内聚，低耦合”的编程思想。

如果项目比较小，这样的分层是没有问题的。但是假设我们业务一直在发展，表示层与业务层的代码肯定是逐渐膨胀的。这就会导致原本清晰的代码变得难以维护。

所以，这时候就需要DDD了。

说到DDD，很多人都会被其中的概念搞晕，比如：领域模型、领域边界、上下文、规约、聚合、值对象等。

其实这么多概念我们先不要去管它，而是要先理解DDD是解决什么问题。

原本在三层架构里，所有业务代码都是放在业务层里的，业务复杂后，就会导致业务代码非常庞大、非常混乱、不好管理。而DDD引入领域的概念，我们把业务划分为不同领域，这样子就能使得业务层变得清晰。但领域与领域之间肯定有关联的、需要相互操作通信的，为了解决这些问题，才会引入那么多的概念。

所以，针对三层架构与DDD架构，我个人更愿意用一句话来说明他们的区别：三层架构是根据代码的不同职责进行分层解耦；而DDD是在三层架构的基础上，对业务按领域进一步解耦。

不管是三层架构还是DDD，都逃不过这六个字：“高内聚、低耦合”，只是他们的划分的程度不同。

我们学习了DDD，可能不会使用到，但至少要了解三层架构的局限在哪里。

对此你有什么其他想法，欢迎留言讨论！