在开发Spring应用程序时，遵循一系列最佳实践可以帮助避免不必要的框架耦合，实现整洁的应用架构。由于这些实践内容较多，将它们分成了几个部分进行介绍。本文将聚焦于如何开始一个新的Spring应用。
如果刚开始一个项目，建议从编写一些业务特性开始。不需要立即配置任何与Spring相关的事项。只需编写一些类，并抽象出需要Spring来处理的所有内容。一旦有足够的业务代码可以交付一些东西，再做决定。如果仍然觉得Spring适合项目，那么现在就是添加它的时候了。
但想要看到应用程序工作！许多人想要从一些基本的Spring配置开始，以确保他们正在构建一个有效的产品。认为应该避免这种思维方式。正在以正确的方式编写正确的事情，这应该通过一组接受测试和单元测试来表达。良好的测试和绿色的IDE状态栏意味着它有效。
这种开始项目的方法有一个巨大的好处。使用它意味着代码是框架独立的，至少在看来，这是一件好事。而且仍然可以自由地改变对框架的想法，直到真正需要交付。
尽管不相信架构图，但应该清楚应用程序的主要部分是什么。为此，创建了一个非常简单的图表，展示了典型的Spring Web应用程序（带有持久性）的高层架构应该是什么样子：
绿色部分是可以使用Spring的部分。在这些组件中，可以直接使用Spring机制。"Web"组与Web界面（MVC/REST）相关的组件。"Main"负责上下文配置，创建业务Bean并注入它们的依赖。"DB"是持久性组件。
红色部分代表具有业务特性的组件。业务组件不应该依赖于Spring或任何Spring相关（绿色）组件。建议将它们放在单独的Maven/Gradle模块中，没有"绿色"依赖。
如果没有充分的理由反对，会在项目中使用Spring Boot来设置Spring。它非常容易配置，所要做的就是添加依赖和一些注解。它具有出色的IDE集成 - 可以通过main方法运行应用程序，使用实时重载来避免为小类更改重新启动整个应用程序等等。此外，它还具有一些在自定义设置中无法拥有的花哨功能，例如，如果使用其父pom，可以获得预配置的依赖版本，这可以防止不兼容性。
看到使用XML配置有几个好处 - 避免了注解地狱，Spring配置（某种程度上）是集中的，并且在配置更改时不需要重新编译任何东西。不幸的是，XML看起来极其不友好（这是主观的，但还没有找到一个喜欢它的人）。长的XML文件是痛苦的。大量的短XML文件甚至更糟糕。
另一方面，Java易于阅读 - 作为Java开发人员，已经习惯了它。在Spring相关的类（如控制器）中使用注解非常方便。无需工作，就可以减少上下文中的Bean数量，这使得它更容易管理（在本系列的后续文章中会有更多内容）。此外，Spring社区普遍倾向于Java配置，看不出有什么理由反对它。
一旦决定使用Java配置，将不得不将Spring配置放入类中。最不想做的事情就是把所有东西都放在一个单独的类中。对于Spring配置，应用用于其他类的相同规则。相关的事物，即"因相同原因而变化"的事物，应该进入一个类。完全不相关的事物，例如，控制器配置和数据库配置，肯定需要进入单独的类。如果决定使用Spring Boot，那么包含main的类不应该包含任何其他配置（当然，除了它上面的注解之外）。