控制器应该围绕用例/业务能力来设计。
要深入这个内容，需要进一步地了解设计REST API的最佳实践。无论你是否想要使用Spring Boot，都是值得学习的。
7、围绕业务功能构建@ServiceService是Spring Boot的另一个核心概念。我发现最好围绕业务功能/领域/用例（无论你怎么称呼都行）来构建服务。
在应用中设计名称类似 AccountService, UserService, PaymentService这样的服务，比起像 DatabaseService、 ValidationService、 CalculationService这样的会更合适一些。
你可以决定使用Controler和Service之间的一对一映射，那将是理想的情况。但这并不意味着，Service之间不能互相调用！
8、使数据库独立于核心业务逻辑之外我之前还不确定如何在Spring Boot中最好地处理数据库交互。在阅读了罗伯特·C·马丁的“Clear Architecture”之后，对我来说就清晰多了。
你希望你的数据库逻辑与服务分离出来。理想情况下，你不希望服务知道它正在与哪个数据库通信，这需要一些抽象来封装对象的持久性。
罗伯特C.马丁强烈地说明，你的数据库是一个“细节”，这意味着不将你的应用程序与特定数据库耦合。过去很少有人会切换数据库，我注意到，使用Spring Boot和现代微服务开发会让事情变得更快。
9、保持业务逻辑不受Spring Boot代码的影响考虑到“Clear Architecture”的教训，你还应该保护你的业务逻辑。将各种Spring Boot代码混合在一起是非常诱人的……不要这样做。如果你能抵制诱惑，你将保持你的业务逻辑可重用。
部分服务通常成为库。如果不从代码中删除大量Spring注解，则更容易创建。
10、推荐使用构造函数注入这一条实践来自Phil Webb（Spring Boot的项目负责人, @phillip_webb）。
保持业务逻辑免受Spring Boot代码侵入的一种方法是使用构造函数注入。不仅是因为 @Autowired注解在构造函数上是可选的，而且还可以在没有Spring的情况下轻松实例化bean。
11、熟悉并发模型我写过的最受欢迎的文章之一是“介绍Spring Boot中的并发”。我认为这样做的原因是这个领域经常被误解和忽视。如果使用不当，就会出现问题。
https://www.e4developer.com/2...
在Spring Boot中，Controller和Service是默认是单例。如果你不小心，这会引入可能的并发问题。你通常也在处理有限的线程池。请熟悉这些概念。
如果你正在使用新的WebFlux风格的Spring Boot应用程序，我已经解释了它在“Spring’s WebFlux/Reactor Parallelism and Backpressure”中是如何工作的。
12、加强配置管理的外部化这一点超出了Spring Boot，虽然这是人们开始创建多个类似服务时常见的问题……
你可以手动处理Spring应用程序的配置。如果你正在处理多个Spring Boot应用程序，则需要使配置管理能力更加强大。
我推荐两种主要方法：
使用配置服务器，例如Spring Cloud Config；
将所有配置存储在环境变量中（可以基于git仓库进行配置）。
这些选项中的任何一个（第二个选项多一些）都要求你在DevOps更少工作量，但这在微服务领域是很常见的。
13、提供全局异常处理你真的需要一种处理异常的一致方法。Spring Boot提供了两种主要方法：
你应该使用HandlerExceptionResolver定义全局异常处理策略；