在做架构设计的时候，一般会采用一些架构模式，便于设计和以后需求变更时修改代码。如果设计模式选择得不正确那么很容易造成架构的混乱，代码也会变成怪物。
分层模式分层模式
分层模式是最常见的模式。我们熟悉的MVC模式就是分层模式的一种。在进行架构设计的时候，如果一筹莫展，那么分层模式是很好的一种尝试。在分层模式中，业务水平切分，分解到不同的层次中，每个层次要求仅相邻的两个层次之间可以进行交互，不可以跨层次进行调用。一般架构会被分成3到5层，具体视架构规模而定，大规模的架构可能会超过5层。在分层模式中，可以很好的解耦，不需要跨层次感知下层的存在。这样带来的好处就是，如果因为某些原因切换了存储，这个时候仅需要修改持久化层就好了，再上面的层次完全感知不到底层的变化。
例外情况
但是这种模式中也会存在些例外，底层有的时候需要对上上层进行部分开放。比如新增加了一个层次，为了适配可能会对一些请求放行，即允许部分跨级调用。
分层模式需要注意的时候，层次必须要做处理，如果当前层次仅仅是对请求的转换，那么就要考虑是否层次拆分得有问题。如果仅做请求转换，那么带来的仅是性能损失和增加新请求时额外的转换代码。
事件模式事件模式1
事件模式2
事件模式有两种形式：
1.带有协调器。协调器作为事件总的入口，监听到事件之后，编排调用处理器，使事件按照业务逻辑进行处理和消费，即协调器监听到事件之后，将事件写入第一个处理器，处理器处理完毕后，协调器再将下一步的业务逻辑事件写到下一个处理器，由此完成业务逻辑。
2.不带有协调器，业务流程的处理靠每个处理器走下去。一个请求到来之后，感兴趣的处理器会处理事件，并产生一个新的事件，并将事件发布到消息队列，对新消息感兴趣的处理器再继续处理新的事件，并再次产生新事件。
这种模式很好的做到了解耦，每个处理器只需要处理自己感兴趣的事件即可。但是因为这些事件都是异步消息，所以容错很难处理。
微内核模式微内核模式
微内核模式也是一种比较常见的模式，比如我们熟悉的eclipse、MySql存储引擎等。在微内核中，核心的业务逻辑包含在内核中，插件提供对功能的加强。一般情况下，内核逻辑是稳定的，新的需求只需要修改某个插件或者新增插件。插件的逻辑比较专注，只需要关注插件内的逻辑即可。对于内核和插件需要规划好连接接口。一定要注意，接口要全面，不能仅局限于当前，不然业务逻辑增加时再增加接口可能会影响到已经存在的插件，使插件不得不进行升级。
式2019-07-21 11:30·java技术小码农
领域结构组织分为三种：事务脚本模式、领域模式和表结构模式。
事务脚本模式
事务脚本模式通常是按照接口的行为而构建的，每个用户的操作都对应一组处理过程。在这种模式下，逻辑层接收到表示层传递下来的参数，通过一系列的处理，将数据保存到数据库，并从数据库获取一些数据加工处理之后返回给表示层。在处理过程中，还可能需要组装其他模块提供的接口。事务脚本模式非常类似脚本的执行，即接收输入，经过一系列的处理再输出结果。这是一种面向过程的模式。在设计时，会将通用的过程抽取出来形成公共调用模块。这种模式的优点是：
1.简单、易理解。这种模式是人人都懂的模式，在实施时对开发人员的要求比较低。
2.具有天然的隔离性。每个用户操作都对应一组处理过程，这些操作都被限定在了当前操作的上下文中。
这种模式的缺点也非常明显：
1.没有办法应对复杂场景。这种模式相当于在上帝视角做设计，需要把处理全部过程放入到一个流程中。当场景复杂时，架构往往会变得非常混乱。
2.有时很难抽取公共处理过程，造成大量重复代码。在这种模式中很容易遇到有些代码逻辑非常相似，可是又有些不同，在抽取公共方法的时候很费力。
3.不具有灵活的扩展性。
领域模型是面向对象的模式
它将逻辑拆分到了不同的对象中，在策略模式的驱动下使这些对象相互作用。面向对象是一种更自然的认识世界的方法。与事务脚本模式的显著区别是，领域模型是一些对象相互作从而影响用户操作，而事务脚本模式是通过一组处理过程响应用户的操作。大型复杂软件都是基于领域模型进行开发的。
这种模式的优点是：
1.能够应对复杂的业务场景。在领域模型中，问题域被划分成不同的限界上下文。在分析问题时，使用通用语言在当前限界上下文中进行分析。小的限界上下文降低了问题的复杂度。
2.高灵活性。领域模型都是高内聚低耦的，能够更加容易的应对变化。
3.抓住问题本质。通过领域模型能够构建行业软件。
这种模式的缺点是：
1.过于复杂，对研发人员要求很高。
2.需要领域专家的参与，不然很难得到正确的领域模型。
表结构模式
表结构模式是事务脚本模式和领域模式的折中方案。这种模式，将表结构映射成对象，并基于这些对象进行设计。这些对象要比领域模式中的对象更加单薄，而且它们都来自于数据表。
在设计过程中，可以根据问题的复杂度、开发人员的能力、开发软件的后续发展等从中选择模式。
领域驱动设计（DDD）在互联网兴起之前很流行，但是互联网的兴起一段时间不再强调领域驱动设计。在互联网处理，业务比较单薄，基本上都是CRUD就能搞定，同时，互联网业务要求快速上线，尽快抢占市场。这些特点导致领域驱动设计的有点没有办法充分的发挥。随着互联网业务的成熟和复杂话，开发人员发现添加新功能变得十分困难，再去回顾软件架构，发现已经变成了“大泥球”。这时领域驱动设计的价值就能够得以体现了。所以现在领域驱动设计开始再次流行起来。
领域驱动设计的目的就是找到行业内通用的模型，非常适合开发行业软件。领域驱动设计是由内而外的，很像修炼“内功”，从领域模型出发，在限界上下文中利用实体、值对象、领域服务等对业务逻辑进行建模。而用例驱动设计则更像是修炼“外功”，从业务用例推导系统用例，通过系统设计、概念设计、开发设计等得到最终的类。如果业务需求变更或者有新需求，领域模型的变化是内聚的、可控的，相对容易很多。
领域驱动设计用一句话来概括就是“在一个限界上下文中使用通用语言去表达业务”。为了能够将业务没有差别的反映到开发模型上，需要使用通用语言将领域专家、架构师和开发人员串联起来。这样可以保证需求可以不失真的反映到代码上。在领域驱动设计中，领域专家是必须的。他们一般在软件所要解决问题的行业浸淫多年，非常熟悉当前的业务逻辑。有了他们，我们才能够非常准确的定义出领域模型。不然是无从谈起领域驱动设计的。
在一般的开发过程中，我们的模型充斥着大量的“贫血模型”。什么是贫血模型呢？贫血模型是只有get和set方法，而没有业务逻辑的模型。在JAVA圈中，很多框架通过反射的方式初始化对象，所以要求必须有相应的get和set方法。从而导致很多人会认为模型就是带有一堆get和set方法而没有业务逻辑的对象。曾经有同事针对“MVC”提了个问题，MVC中的M是指“模型”，可以模型只是带有数据的对象的而已，怎么会把这种对象跟V和C相提并论，感觉不到模型存在的意义。其实是贫血模型使他对模型产生的误解，认为贫血模型就是所谓的“模型”。贫血模型有什么缺点呢？由于贫血模型不带有业务逻辑，导致业务逻辑都分散到使用模型的应用层了，多个模型的业务逻辑在应用层交织在一起，导致了“大泥球”，对以后需求的变更和新需求的添加造成了阻碍。
领域驱动设计的目的就是建立能够反映业务的模型，模型的业务逻辑内聚，可复用性强。
