Java分层架构：起源、设计原则与演进-优快云博客

java 分层架构的由来

目录
参考资料和推荐阅读

Survive by day and develop by night.
talk for import biz , show your perfect code,full busy，skip hardness,make a better result,wait for change,challenge Survive.
happy for hardess to solve denpendies.

认识分层架构
分层架构是运用最为广泛的架构模式，几乎每个软件系统都需要通过层（Layer）来隔离不同的关注点（Concern Point），以此应对不同需求的变化，使得这种变化可以独立进行；此外，分层架构模式还是隔离业务复杂度与技术复杂度的利器，《领域驱动设计模式、原理与实践》写道：

需求：

设计思路

其实就是引起变化的原因各有不同，这正好是单一职责原则（Single-Responsibility Principle，SRP）的体现。Robert Martin 认为单一职责原则就是“一个类应该只有一个引起它变化的原因”，换言之，如果有两个引起类变化的原因，就需要分离。单一职责原则可以理解为架构原则，这时要考虑的就不是类，而是层次。我们为什么要将业务与基础设施分开？正是因为引起它们变化的原因不同。

实现思路分析

经典三层架构
在软件架构中，经典三层架构自顶向下由用户界面层（User Interface Layer）、业务逻辑层（Business Logic Layer）与数据访问层（Data Access Layer）组成。该分层架构之所以能够流行，是有其历史原因的。在提出该分层架构的时代，多数企业系统往往较为简单，本质上都是一个单体架构（Monolithic Architecture）的数据库管理系统。这种分层架构已经是Client-Server架构的进化了，它有效地隔离了业务逻辑与数据访问逻辑，使得这两个不同关注点能够相对自由和独立地演化。一个经典的三层架构如下所示：

这正好是单一职责原则（Single-Responsibility Principle，SRP）的体现。Robert Martin 认为单一职责原则就是“一个类应该只有一个引起它变化的原因”，换言之，如果有两个引起类变化的原因，就需要分离。单一职责原则可以理解为架构原则，这时要考虑的就不是类，而是层次。我们为什么要将业务与基础设施分开？正是因为引起它们变化的原因不同。

追溯分层架构的本源

视分层（Layer）为一个固有的架构模式，其滥觞应为 Frank Buschmann 等人著的《面向模式的软件架构》第一卷《模式系统》。该模式参考了 ISO 对 TCP/IP 协议的分层。《模式系统》对分层的描述为：

分层架构模式有助于构建这样的应用：它能被分解成子任务组，其中每个子任务组处于一个特定的抽象层次上。

该怎么演进领域驱动架构？
我们在上文中回顾了经典三层架构与领域驱动设计四层架构，然而任何技术结论都并非句点，而仅仅代表了满足当时技术背景的一种判断，技术总是在演进，领域驱动架构亦是如此。与其关心结果，不如将眼睛投往这个演进的过程，或许风景会更加动人。