领域驱动设计DDD（Domain Driven Design）提出了从业务设计到代码实现一致性的要求，不再对分析模型和实现模型进行区分。也就是说从代码的结构中我们可以直接理解业务的设计，命名得当的话，非程序人员也可以“读”代码。这与微服务设计中的约定优于配置不谋而合，如果你熟悉英文，那么直接根据包名和类名就可以直接解读出程序开发者所构建的业务的大概意图。
领域模型包含一些明确定义的类型：
实体是一个对象，它有固定的身份，具有明确定义的"连续性线索"或生命周期。通常列举的示例是一个 Person（一个实体）。大多数系统都需要唯一地跟踪一个 Person，无论姓名、地址或其他属性是否更改。
l值对象没有明确定义的身份，而仅由它们的属性定义。它们通常不可变，所以两个相等的值对象始终保持相等。地址可以是与 Person 关联的值对象。
l集合是一个相关对象集群，这些对象被看作一个整体。它拥有一个特定实体作为它的根，并定义了明确的封装边界。它不只是一个列表。
l服务用于表示不是实体或值对象的自然部分的操作或活动。
领域模型在实现时可大可小，在业务的早期，在系统比较小的情况下，它有可能是一个类。当系统做大了以后，它可能是个库。再做更大一点的时候，它可能是一个服务，给不同的应用去调用。
要将领域元素转换为服务，可按照以下一般准则来完成此操作：
使用值对象的表示作为参数和返回值，将集合和实体转换为独立的微服务。
将领域服务（未附加到集合或实体的服务）与独立的微服务相匹配。
每个微服务应处理一个完整的业务功能。
领域模型又可以分为失血、贫血和充血3种。
失血模型：基于数据库的领域设计方式就是典型的失血模型，只关注数据的增删改查。
贫血模型：就是在domain object包含了不依赖于持久化的领域逻辑，而那些依赖持久化的领域逻辑被分离到server层。
充血模型：充血模型跟贫血模型差不多，不同的是如何划分业务逻辑，就是说，约大部分业务应该放到domain object里面，而service应该是很薄的一层。
设计原则之分层架构同一公司使用统一应用分层，以减少开发维护学习成本。应用分层这件事情看起来很简单，但每个程序员都有自己的一套，哪怕是初学者，所以想实施起来并非那么容易。
最早接触分层架构的应该是我们最熟悉的MVC（Model-View-Controller）架构，将应用分成了模型、视图和控制层，可以说引导了绝大多数开发者，而我们现在的应用中非常多的包括框架，架构设计都使用此模式。这后又演化出了MVP（Model-View-Presenter）和MVVM（Model-View-ViewModel）。这些可以说都是随着技术的不断发展，为了应对不同场景所演化出来的模型。而微服务的每个架构都可以再细分成领域模型，下面看一下经典的领域模型架构。
它包括了Domain，Service Layer和Repositories。核心实体（Entity）和值对象（Value Object）应该在Domain层，定义的领域服务（Domain Service）在Service Layer，而针对实体和值对象的存储和查询逻辑都应该在Repositories层。值得注意的是，不要把Entity的属性和行为分离到Domain和Service两层中去实现，即所谓的贫血模型，事实证明这样的实现方式会造成很大的维护问题。基于这种设计，工程的结构可以构造为：
- MicroService-Sample/src/
domain
gateways
interface
repositories
services
当然，在微服务的架构中，每个微服务不必严格遵照这样的规定，切忌死搬硬套，最重要的是理解，在不同的业务场合，架构的设计可以适当的做调整，毕竟适合的架构一定要具有灵活性。
分层的原则包括：
文件夹分层法
应用分层采用文件夹方式的优点是可大可小、简单易用、统一规范，可以包括 5 个项目，也可以包括 50 个项目，以满足所有业务应用的多种不同场景。
调用规约
在开发过程中，需要遵循分层架构的约束，禁止跨层次的调用。
下层为上层服务
以用户为中心，以目标为导向。上层（业务逻辑层）需要什么，下层（数据访问层）提供什么，而不是下层（数据访问层）有什么，就向上层（业务逻辑层）提供什么。
实体层规约
Entity是数据表对象，不是数据访问层对象；DTO 是网络传输对象，不是表现层对象；BO 是内存计算逻辑对象，不是业务逻辑层对象，不是只能给业务逻辑层使用 。如果仅限定在本层访问，则导致单个应用内大量没有价值的对象转换。以用户为中心来设计实体类，可以减少无价值重复对象和无用转换。
U 型访问
下行时表现层是 Input，业务逻辑层是 Process，数据访问层是 Output。上行时数据访问层是 Input，业务逻辑层是 Process, 表现层就 Output。