微服务业务层如何进行分层？业务系统如何定级，标准为什么？

设计原则之分层架构
同一公司使用统一应用分层，以减少开发维护学习成本。应用分层看起来很简单，但每个程序员都有自己的一套方法，哪怕是初学者，所以想实施起来并非那么容易。

最早接触的分层架构应该是我们最熟悉的MVC（Model-View-Controller）架构，其将应用分成了模型、视图和控制层，可以说引导了绝大多数开发者。而现在的应用（包括框架）中非常多架构设计都使用此模式。之后又演化出了MVP（Model-View-Presenter）和MVVM（Model-View-ViewModel）。这些可以说都是随着技术的不断发展，为了应对不同场景所演化出来的模型。而微服务的每个架构都可以再细分成领域模型，下面看一下经典的领域模型架构。

它包括了Domain、Service和Repositories。核心实体（Entity）和值对象（Value Object）应该在Domain层，定义的领域服务（Domain Service）在Service层，而针对实体和值对象的存储和查询逻辑都应该在Repositories层。值得注意的是，不要把Entity的属性和行为分离到Domain和Service两层中去实现，即所谓的贫血模型，事实证明这样的实现方式会造成很大的维护问题。基于这种设计，工程的结构可以构造为：

• MicroService-Sample/src/

  domain

  gateways

  interface

  repositories

  services

当然，在微服务的架构中，每个微服务不必严格遵照这样的规定，切忌死搬硬套，最重要的是理解业务。在不同的业务场合，架构的设计可以适当地调整，毕竟适合的架构一定要具有灵活性。

分层的原则如下

Ÿ 文件夹分层法

应用分层采用文件夹方式的优点是可大可小、简单易用、统一规范，可以包括5个项目，也可以包括50个项目，以满足所有业务应用的多种不同场景。

Ÿ 调用规约

在开发过程中，需要遵循分层架构的约束，禁止跨层次的调用。

Ÿ 下层为上层服务

以用户为中心，以目标为导向。上层（业务逻辑层）需要什么，下层（数据访问层）就提供什么，而不是下层（数据访问层）有什么，就向上层（业务逻辑层）提供什么。

Ÿ 实体层规约

Entity是数据表对象，不是数据访问层对象；DTO是网络传输对象，不是表现层对象；BO是内存计算逻辑对象，不是业务逻辑层对象，不是只能给业务逻辑层使用。如果仅限定在本层访问，则导致单个应用内大量没有价值的对象转换。以用户为中心来设计实体类，可以减少无价值重复对象和无用转换。

Ÿ U型访问

下行时表现层是Input，业务逻辑层是Process，数据访问层是Output。上行时数据访问层是Input，业务逻辑层是Process，表现层是Output。