DDD其实特别好理解，DDD就是领域来驱动设计嘛，是一种设计思想。很容易又和OOA、OOD和OOP来比较了。这个回头再说。
SOA、微服务和微内核都是架构风格，DDD里能和他们三个放在一起比较的是四层架构和六边形架构。
四层架构
四层架构长这样：
图片
分为用户接口层、应用层、领域层和基础层，四层架构目的是为了解耦，下层不依赖上层，从依赖关系上讲，四层架构的箭头是反过来的。
目前这个架构，在现代系统中，通常用作项目工程模块的设计。就是说更传统的MVC逐渐被淘汰，目前主流就是这种四层架构。有的项目工程会先用限界上下文划分子域，再用四层架构。然后代码结构长这样：
├─interfaces API接口层
│ ├─dto 视图模型,数据模型定义 vo/dto（大多数情況是一样的）
│ └─controller 控制器，对外提供（Restful）接口
│
├─application 应用层
│ ├─service 应用服务，非核心服务
│ └─*** others
│
├─domain 领域层
│ ├─entity 领域实体、聚合根，充血的领域模型
│ ├─valueobject 领域值对象
│ └─service 领域服务类，一些不能归属某个具体领域模型的行为
│
├─infrastructure 基础设施层
│ ├─po 持久化对象
│ ├─repository 仓储类，持久化接口&实现，可与ORM映射框架结合
│ ├─dao 数据访问对象
│ ├─client feign等调用客户端
└─ └─factory 工厂类，负责复杂领域对象创建，封装细节底层实体采用充血模型，有一些聚合，形成聚合根。与存储层的交互封装在仓库中，用DDD工厂来管理仓库。上层会将实体转换成贫血模型再暴露出去。你们项目的结构，架构师是不是这样定义的？
六边形架构
六边形架构很多文章作者把这个架构分成几层，这些都是加上了作者个人的理解。实际上六边形架构又叫洋葱形架构很简单，就是个端口适配器模式。外六边形是技术域，内六边形是业务域。这个常用于一些整体架构中。比如说基于一些基础组件做二次开发。真正的业务实现是组件实现的，有一些专门的维护人员。但是团队中往往会有更多成员在做封装接口暴露给公司内的用户，做高可用或者自动化运维这些通常所说的外层。这个外层就是六边形架构里技术域解决的问题。
图片
SOA和微服务架构
SOA的出现是为了解决功能复用的问题，将一些共通的模块提取出来做成服务。这个我之前在开发中发现不好用，仅次于单体应用时各个模块引入一个common的jar包。因为这些共通的模块很可能适应不了各方面的需求，上层的需求总有一些差异。这样的情况下，这个共通模块就不太好维护了。
服务化的概念使得上世纪就已经产生的DDD得到了大家的关注。因为DDD解决了怎么服务化的问题，就是划分领域。微服务就是服务化之后划分粒度的问题了。
微内核架构
微内核架构又叫插件化架构，包含两类组件：核心系统（core system）和插件模块（plug-in modules）。核心系统负责和业务无关的通用功能，例如模块加载、模块间通信等；插件模块负责实现具体的业务逻辑，例如“学生信息管理”系统中的“手机号注册”功能。
核心系统（Core System）功能一般比较稳定，不会由于业务扩展而不断修改，插件模块需要根据业务功能的发展不断地扩展。微内核的架构本质是将变化部分封装在插件里，从而实现快速灵活扩展的目标，而同时又不影响整体系统的稳定。常见的例子有：Eclipse IDE、Spring、Dubbo。
我做过一个配置化项目。把业务流程划分成模块，会不断有新业务接入进来，很多模块都可以复用。比如业务A需要a\b\c三个模块，业务B需要a\c\d\e四个模块，那新业务进来只需要进行模块流程的配置。如果需要的模块没有，那就以插件的形式集成进来再进行配置。我们称这个服务采用的是微内核架构，目的就是要让大家把新功能的开发做插件式开发，避免对旧功能的影响，提高系统的稳定性。
