演进原则
任何产品的演进都无法一蹴而就，在架构演进过程中需遵循以下几方面的原则。
- 渐进性原则，满足当前及未来一定范围的技术要求，可做到平台的平滑过渡升级。
- 独立性原则，逐渐拆分的微服务要具有一定的独立性，以能力方式对上层应用服务提供特定的业务能力支持，要与其他服务保持相对无关性。比如独立的文件服务、licence授权服务、工作流服务等等。
- 无状态原则，微服务要保证基本无状态，便于微服务自身的集群构建及独立迭代优化。
划分原则
把一个大系统划分为多个微服务，使模块间结构更加清晰，模块间更低耦合高内聚，有更好的扩展性和稳定性。微服务划分务必遵守以下原则：
- 按功能模块划分微服务，尽量做到一个功能模块一个微服务。
- 微服务之间减少互相调用，做到低耦合高内聚。
项目划分
- mes-base 共有基础模块，抽出共用实体，共用工具类等
- mes-discovery-nacos 服务注册中心
- mes-api-gateway 网关
- mes-config 配置中心
- mes-user 用户模块
- mes-equipment 设备管理模块
等等，具体根据业务做具体划分。
“万能模板”是什么
在云原生技术实践联盟（CNBPA）2021 年初的调研中显示，国内 72.7%的企业已经采用 Kubernetes 作为容器编排技术，占据了绝对的优势地位。这也与 CNCF 最新发布的中国区云原生调查报告中，72%的受访者已经在生产环境当中使用 Kubernetes 的数据保持相当高的一致性，同期全球调查报告的数字是 78%。
在云计算建设和技术引入时，建议考虑基于以 Kubernetes 为核心的云原生平台来做，Kubernetes 作为云的操作系统，可以屏蔽下面各种各样不同的云环境、云基础设施，它自身是一个可移植层，这样在做混合云和多云管理时，对应用迁移以及其他工作负载非常有好处，可以做到跨环境的兼容。由于 Kubernetes 的可扩展性，本身平台之平台的属性，导致它天生适合用来作为整个混合云的控制面板，用它去编排不同类型的云环境以及云基础设施和各类云服务。
在建设路线上应该以应用为中心，覆盖应用全生命周期为目标进行云计算的建设方向。充分考虑平台融合基础设施、微服务框架、数据服务、DevOps 工具等模块作为平台组件，以建设具备全栈能力的云平台为发展方向。
应用转型的相关规范
建议可以参考以下 15 个要素，这些要素几乎涵盖了云原生架构下应用转型的各个方面。
要素 1：基准代码（Codebase）——一份基准代码，多份部署。
要素 2：依赖（Dependencies）——显式地声明依赖关系。
要素 3：配置（Config）——在环境中存储配置。
要素 4：后端服务（Backing Services）——把后端服务当作附加资源。
要素 5：构建、发布、运行（Build、Release、Run）——严格分离构建、发布、运行。
要素 6：进程（Processes）——以一个或多个无状态进程运行应用。
要素 7：端口绑定（Port Binding）——通过端口绑定提供服务。
要素 8：并发（Concurrency）——通过进程模型进行扩展。
要素 9：易处理（Disposability）——快速启动和优雅终止可最大化健壮性。
要素 10：开发环境与线上环境等价（Dev and Prod Parity）——尽可能保持开发、预发布、线上环境相同。
要素 11：日志（Logs）——将日志当作事件流。
要素 12：管理进程（Admin Processes）——将后台管理任务作为一次性进程运行。
要素 13：优先考虑 API 设计（API First）。
要素 14：通过遥测感知系统状态（Telemetry）。
要素 15：认证和授权（Authentication and Authorization）
领域划分的规则或者原则
单一抽象层次原则
这个原则其实要求做领域划分的时候不可以抽象出多个相似的领域，比如营销和优惠，这两个可能就是相似的领域，或者说优惠是在营销领域下的一个层次的抽象，那这样的话我们可以用这个原则来检查一下划分的领域有没有可能存在相似和重复。当然另外一方面也可以保障我们可以识别大多数的重要领域。
奥卡姆剃刀原理
这里说的意思是在划分上下文的时候不要做的太细，太细的话就存在多个层次的内容反而无法更好的切分上下文，那么在领域层也类似，说白了，通过这个原理可以让主观的划分更有能动性，也更能给出划分的理由。即使是拍脑袋划分的，能从中取出核心的领域名称并给出具有说服力的理由也算一种划分方案。
最小惊讶原则
这个原则说的是在真正懂行的专家里或者有经验的大佬面前如果你的划分挺合理的话那么他们不会感到惊讶，可能会会心一笑。反之就会觉得有需要改进的地方，或者再讨论讨论。所以在领域和上下文的划分上来看，如果划分的比较合理那么就没有太多争论的必要了。
正交原则
这个正交原则其实可能有点不太理解或者不容易应用，在领域划分方案出来之后可以通过一些业务流程来看一下领域内的聚合实体服务等是否跟别的领域内做的事情相似或者一样，如果存在的话说明还可以继续优化。直到每个领域做的事情都足够唯一或者职责单一，到合适的正交维度即可。如果过度的追求正交和职责单一可能会出现单一抽象层次不清晰的情况。
多数派原则
简单解释一下，就是可以从统一语言或者领域名称中找一些线索，比如我们有很多业务流程，有很多用例或者用户故事，那么这些文档和业务中哪些出现的名词或者动名词最多这个就可以作为一个领域。目前看这是一种最简单的领域划分原则了，也就是说你可以从脑海中过一遍所有业务流程，接口流程，调用时序，从统一语言上去统计哪些词语是最常出现的，这些词语代表了哪个维度的领域，是核心领域还是通用领域，还是依赖领域等等。那么可以把这些词语单独摘出来去划分，当然也可能有最多的排序，比如出现词语最多的有 20 个，但是里面可能有重复的，不够正交也不够单一抽象，那么可以用排除法一一去舍掉看是否是最好的领域划分方案，类似于手动寻找最优解。