大泥球式的代码
软件开发过程中，因为缺少代码规划，没有组织，使得代码混在一同。 这样带来的问题： 1）没有把范畴逻辑独立出来，导致代码坚持与模型共同。
2）代码难理解，应该内聚的逻辑散在不同的地方，应该解耦的代码混在一同
3）技能代码/事务代码混在一同，可维护性差
4）代码重复，可维护难度越来越大
以上便是大泥球式代码。
分层架构 – 解决大泥球式代码的最佳实践
分层架构把代码分红若干层，每层担任不同的关注点。图里的箭头表示依靠关系，这儿的意思是只能外层依靠内层，内层不能依靠外层。
依据软件架构中的一个重要准则：代码中不安稳的部分，应该依靠安稳的部分。所以，分层架构中越是内层，就越安稳，越是外层，相对就越简略改变。
分而治之。
怎么划分代码的层次
别离范畴 – 范畴层
范畴层处于咱们架构的最内层，是整个体系的核心，是 DDD 的基本理念。
模块级：在 domain 包里，咱们要依据范畴模型中的模块进一步分包。这样，就保证了在模块一级代码和模型的共同性。下面这张图包含了范畴层和模块的程序结构：
实体级：按模块分包以后，咱们接着依照范畴模型，在模块包中建立实体类，这样就能在类的层面和模型坚持共同了。这儿先为每个类写一个“空壳”。
给范畴一个门面 – 应用层
在范畴层外面再加一层，DDD 和六边形架构都将这一层称为 Application，也便是应用层。
2）将范畴层的处理结果封装为更简略的粗粒度目标，作为对外 API 的参数。这儿说的粗粒度目标一般是 DTO（Data Transfer Object），也便是没有逻辑的数据传输目标，应用层担任 DTO 和范畴目标的数据转化；
3）担任处理事务、日志、权限等等横切关注点。从规划方式的视点，这一层相当于“门面”（Facade）方式，
封装应用逻辑的类通常没有状态，只要方法，一般称为应用服务，咱们能够用 XxxService 的方式来命名。下面便是增加了一些首要应用服务的代码结构：
用“适配器”处理输入输出
除了事务功用之外，程序里还有另一个重要的关注点——输入输出技能。咱们的体系要和外界打交道，能够经过不同技能来完成，比方 Restful API、 RPC，以及传统的 Web 页面等等。
不论详细技能是哪一种，背面完成的事务功用很或许都是相同的。所以，输入输出技能和事务功用是两个不同的关注点。
六边形架构中将这层称为适配器，英文是 adapter。这是因为，这一层的意图是把事务功用“适配”到不同的输入输出技能。
说适配器层屏蔽了输入输出技能的差异，从而使应用层与详细技能无关，这样就达到了别离关注点的意图。
下图是增加了适配器层的代码结构：
Restful 包里是 Resful Api，web 包里面是传统的 JSP 页面。这些包里的适配器，在多数情况下，便是咱们熟悉的 Controller。
用“适配器”处理数据耐久化
数据处理耐久化：包含数据库、缓存、文件体系、目标存储器。
DDD 里的另一个方式，叫做 Repository，中文能够叫库房。这个方式用于封装耐久化的代码，大体上类似于传统上说的 DAO（Data Access Object），也便是“数据拜访目标”。 和 DAO 不同的是，库房是以聚合为单位的，每个聚合有一个库房，而 DAO 是以表为单位的，每个表有一个 DAO。
库房和适配器有什么关系
咱们需求一种适配器把详细的耐久化技能和应用层以及范畴层隔脱离，而库房就充当了这种适配器。 Controller 处理的是从外界向体系的调用，比方说来自 HTTP 客户端的调用；而库房处理的是由体系向外界的调用，比方说对数据库的调用。也便是说，两者的方向不同。
在六边形架构里，把由外向内的适配器叫做 driven adapter，我把它译作被迫适配器；而由内向外的适配器叫做 driving adapter，能够译作自动适配器。准确地说，自动适配器的效果不限于拜访数据库，而是拜访一切外部资源。
存放通用东西和结构 – common 层
东西类和结构，这些代码或许被前面的一切层依靠，那么是不是说，这些代码应该处于整个体系的最内层呢？假如这样做，那么和 DDD 所强调的以范畴层为核心的思维就矛盾了。但假如不这么做，是不是又违反了层间依靠准则呢？
咱们能够以为这些代码和前面说的各层底子不在同一个维度，它们是对各层代码起到公共的支撑效果的。用下面这张图比较简略说明这个思路：
结构和东西的差异一般是，结构会调用咱们自己写的代码，而东西则被咱们写的代码所调用。
分层架构的权衡
希望你能够理解分层架构背面的原理，然后针对自己项目中存在的痛点进行权衡，构成适合自己项意图架构标准。 在实践项目中，有些层次能够兼并，有些层次则能够分得再细。在下面的表列出了几种分层架构的改变：
极客时间《手把手教你落地DDD》学习笔记 Day9
