目前公司系统多个应用分层结构各不相同，给运维和未来的开发带来了巨大的成本，分层架构看似很简单，但保证整个研发中心都使用统一的分层架构就不容易了。
那么如何保证整个研发中心都使用统一的分层架构，以达到提高编写代码效率、保证工程统一性的目的？
这里给出个人的规划设计，希望对你有所启发。
1.分层目标简单易用：少即是多，哪怕应届生进来也能很快上手
结构统一：不管是新系统还是旧系统结构的是一样的。
提高效率：提高开发和运维效率，减少维护和学习成本
2.分层架构介绍先简单介绍当前两种比较流行的分层架构体系：领域分层架构和传统三层架构
2.1领域分层架构领域架构：包括仓储层、领域层、应用服务层、表现层和基础公共层，如下图所示：
另一种是相对传统地分为三层：包括数据层、业务逻辑层和表现层，如下图所示：
在早期做三层架构的时候，大都以表来驱动，在做领域架构的时候，大都以业务逻辑来驱动，两者的区别确实比较明显，但到了现在，如果都以业务逻辑为中心，那么两者并没有本质区别。
携程公司采用了第二种分层法，他们希望把分层做得极简，也就是说，哪怕刚毕业进入公司的员工，在分层时基本上也不会乱。
相对于第一种分层法，第二种分层法简单得多。每一个应用的代码量都不应该很大，一旦工程变得过大，就会把它适当拆分，而不是全部放在一单体应用里。
总之，分层越简单，整个软件结构就越清晰，代码就越容易统一。
把工程做得极简，才有利于复制，有利于业务的快速构建，有利于规模化，使系统稳定可靠。
3.统一分层规范以上两种逻辑分层如何做选型？我们要回到分层的目的上来评估，我们的目标是简单、统一、高效。所以传统的三层架构很好的满足了我们的需求。而领域驱动开发，对DDD有一定的学习成本，同时对旧系统的历史包袱，比如数据库，我们无法做到面向领域编程，我们更多的要面向数据库编程。所以，当前敏捷框架比较适合想从老系统迁移的，但是有数据库历史包袱的团队。如果您的项目中不存在历史包袱，那么可以参考我的另外一篇的设计文章：《开箱即用~基于.NET Core的敏捷开发框架》
减少私人通用帮助类CommonLayer的编写，如果每一个应用中有大量相同的帮助类，则在架构层面上是有问题的。线上应用越多，则代码重复越多。比如，每个应用都有分页帮助类、数据库帮助类、缓存帮助类、MQ帮助类、日志帮助类、AOP帮助类等。
每一个应用都是特别的，都需要私人定制极少有通用的代码，如果有，那么应该由框架或组件专门解决。这里框架统一放在Com.Util里。