领域驱动设计概览
领域驱动设计（Domain Driven Design，DDD）是由Eric Evans最早提出的综合软件系统分析和设计的面向对象建模方法，如今已经发展为一种针对大型复杂系统的领域建模与分析方法。它完全改变了传统软件开发工程师针对数据库进行的建模方法，从而将要解决的业务概念和业务规则转换为软件系统中的类型以及类型的属性与行为，通过合理运用面向对象的封装、继承、多态等设计要素，降低或隐藏整个系统的业务复杂性，并使得系统具有更好的扩展性，应对纷繁多变的现实业务问题。
领域驱动设计中的架构要素
多数时候，领域驱动设计的分层架构并不能清晰表达各模块之间的依赖关系，以及这些模块在分层架构中所处的位置。因为我倾向于将Uncle Bob的Clean Architecture与DDD的分层架构整合起来，如下图所示：
在这个架构图中，基础设施层处于最外部，然后是应用层，最核心的是领域层。基础设施中的模块，我都称之为gateway。根据依赖方向，如果是被调用的方向，即由外至内的调用方向，就是北向，称之为北向网关。如果当前限界上下文是通过该网关调用外部资源或者别的限界上下文，即由内至外的调用方向，则是南向网关。例如图中的OrderController，会被别人调用，因而属于北向网关。注意，倘若OrderController通过RESTful方式暴露API，即为REST服务，也就是基于资源的服务。我们不能将它与DDD的应用服务混为一谈。
领域驱动设计，重焕青春的设计经典
领域驱动设计确实已不再青春，从Eric Evans出版那本划时代的著作《领域驱动设计》至今，已有差不多十五年时间。在软件设计领域，似乎可以称得上是步入老年了。可惜的是，对于这样一个在国外IT圈享有盛誉并行之有效的设计方法学，国内多数的技术人员却并不了解，也未曾运用到项目实践中，真可以说是知音稀少。领域驱动设计似乎成了一门悄悄发展的隐学，它从来不曾大行其道，却依旧顽强地发挥着出人意料的价值。
直到——直到行业内吹起微服务的热风，人们似乎才重新发现了领域驱动设计的价值。并不是微服务拯救了领域驱动设计，因为领域驱动设计一直在坚硬的生长，然而看起来，确乎因为微服务，领域驱动设计才又焕发了青春。
为什么我们需要正确地领域建模
广而告知：我在GitChat的领域驱动战略设计实践达人课已经发布，目前正在进入预售期。打开链接即可查看与订阅。同时，我还将在我的个人公众号上做抽奖活动，对于积极评论者会有本次课程的免费码赠送，敬请期待！
在领域驱动设计过程中，正确地进行领域建模是至为关键的环节。如果我们没有能够从业务需求中发现正确的领域概念，就可能导致职责的分配不合理，业务流程不清晰，出现没有任何领域行为的贫血对象，甚至做出错误的设计决策。
《架构之美》评注版序
软件架构终归属于工程学的范畴，不能一概以“只可意会不可言传”来搪塞，因为架构知识是可以传递的，架构文档是可以共享的，最重要的是，架构自身是可以评审、验证与实现的。