java分层model_你的分层架构还好吗？

原标题：你的分层架构还好吗？

分层架构，不就是建文件夹的艺术吗？

注：本文更适用于中大型项目，小项目开心就好了。因为时代的原因，对部分词汇描述可能不是那么准确，欢迎指正。

当我们开始一个新的项目，我们就开始创建一个个折文件夹。哦，不对，那我们在做分层架构设计。架构最后落到现有的计算机操作系统上，其的展示形式是分层架构。毕竟，硅基不如碳基。

可是呢，为什么我们要做分层架构设计呢？通过层(Layer)来隔离不同的关注点。

So，我要开始瞎扯了。

基本思想：关注点分离，划分边界

注：三层架构(controller-service-model)并非等于于 MVC 架构模式。对于其的错误等同，导致了架构上的一系列错误。

问题：落后的三层架构

过去，我总以为对于大部分项目来说，三层分层架构之外的部分是大泥球，即随意化的代码组织方式。然而，我发现对于大部分的项目来说，三层分层架构的 service 也是个大泥球，我忘记了三层分层架构的 model 层也是一堆大泥球。Controller 相对好一点，但是对于某些项目来说也是个小泥球。

大泥球是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑，往往会导致很多错误或者缺陷。

在今天 DDD + 整洁架构流行的今天， 三层分层架构已经完全不能满足现有应用的需求，甚至看上去一团糟糕。它存在这么一些问题：

统一管理是魔鬼，如 controller 文件夹下一堆的代码，到处乱放的 model。

缺乏明确的职责划分，如 controller 承担了 service 的职责

臃肿的 service，和贫血的 model

三层分层之后的随意文件组织方式，如 kafka 等到处乱放的代码

可是，为什么会这样呢？

职责(or 限界上下文)没有划分明确和清晰

model 层存在大量的二义性

技术导向架构模式

于是，我们有了一些基本的解决方案，或者说是套路。

重新定义：消除二义性

当我们谈论 service 的时候，我们谈论的是同一个 service 吗？

当我们谈论 model 的时候，我们谈论的是同一种 model 吗？

若对于一个文法的某一句子存在两棵不同的语法树，则该文法是二义性文法。

如果有多种不同类型的类，都被放置在 model 包下。那么，你应该消除 model 这个包，改为更表意的名称，如 Entity、* Request、* Response 等等。同理，一旦你们展开对某个名称的讨论时，是时候好好考虑其中的二义性。

最后，你还需要有一个相关领域的名词表。

划分边界：业务导向架构

开始之前不得不说的是ÿ