超级会员免费看
本文探讨了如何通过领域驱动设计（DDD）的分层架构来解决代码组织问题，避免“大泥球”现象。介绍了分层架构的各个层次，包括领域层、应用层、适配器层（被动适配器和主动适配器）以及公共支撑层（common），并解释了各层之间的依赖关系和职责。此外，文章还强调了分离领域层的重要性，以确保与领域模型的一致性。
文章目录
【DDD（领域驱动设计）思想解读及优秀实践 09】｜分层架构：怎样逃离“大泥球”？
上节课，我们完成了数据库设计，解决的是怎样保证数据库和领域模型一致的问题。接下来，我们来解决怎样保证代码与模型一致的问题。
这个问题又分成两个层面。第一个层面是要有一个合理的代码架构，第二个层面是更详细的代码编写。今天我们主要解决第一个层面的问题，通过引入DDD的分层架构，建立代码的骨架。
我们这节课的方法综合了《领域驱动设计：软件核心复杂性应对之道》（后面简称《DDD》）这本书里的内容以及“六边形架构”的思想。六边形架构是由敏捷软件开发专家 Cockbun提出的，用来分离技术和非技术关注点。如果你只是想掌握分层架构的最佳实践，那么学习这门课就可以了；
那么，我们为什么要采用分层架构呢？原因就是为了避免“大泥球”式的代码。
逃离“大泥球”
我们知道，系统中的代码都有各自的目的，有些处理领域逻辑，有些处理用户界面，有些处理数据库的访问……这些代码的关注点各不相同。但在很多开发团队中，并没有明确的手段来分离代码的关注点，从而使不同关注点的代码混在一起，这样就会造成下面几个问题：
订阅专栏 解锁全文
扫一扫
934
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
