Polylith 是一种软件架构，可以解决构建后端系统的一些基本挑战。这些挑战是：
- 跨团队和服务共享我们的代码很困难
- 我们缺乏一种用于交流建筑概念的共享语言
- 随着我们代码库的增长，它们往往会变得一团糟，难以更改和测试
- 我们尝试在我们的开发环境中模仿我们复杂的生产环境
- 我们的系统需要很长时间来测试、构建和部署
Polylith 是一种在系统规模上应用功能性思维的软件架构。它帮助我们构建简单、可维护、可测试和可扩展的后端系统。
Polylith 通过引入简单、可组合、类似乐高积木的积木来解决这些挑战，这些积木可以轻松地在团队和服务之间共享。
为了让开发体验更加愉快，我们还构建了一个工具，可以即时创建各种构建块、增量测试（仅测试受上次更改影响的代码）和项目可视化。
什么不是 Polylith
- Polylith 不是一个框架，也没有随时可用的功能。
- Polylith 不是库包。
- Polylith 不是工具（但对 Clojure 有工具支持）。
Polylith 适用于哪些编程语言？
Polylith 与语言无关，几乎可以在任何编程语言中使用它。到目前为止，我们在 Polylith 团队中只将它与函数式语言Clojure一起使用，但没有什么能阻止有人在像C这样的过程语言或像Java这样的面向对象语言中使用它，我们在这里有一个例子。即使没有工具支持，您也将获得大部分好处。
当前架构问题
我们将用三种主流软件架构来描述我们的开发和生产经验。但我们将首先定义我们的术语：
- 单体：一种软件架构，其中代码存储在单个代码库中并作为单个工件部署
- 微服务：由小型且可独立部署的服务组成的软件架构；每个服务都在一个单独的进程中运行，并通过网络与其他服务进行通信
- 无服务器：基于云计算执行模型的软件架构；在云供应商动态管理计算机资源的分配
这些架构为我们提供了大量关于如何部署系统的指导，但很少指导如何在每个系统中构建我们的代码。多年来，我们尝试了许多不同的方法来改进我们系统的内部结构（例如DCI、DDD、设计模式、SOA、SOLID、Hexagon等），但没有一种方法是能将我们带到开发的必杀技。
为了实现这一目标，我们意识到我们需要卷起袖子，发明一种全新的方法。
Polylith 的单一开发项目使我们能够在一个地方使用我们所有的构建块。这将我们的开发经验与我们选择的部署架构脱节。
将开发与部署分开使我们能够将部署决策推迟到最后一刻。这种延迟使我们能够避免“过早分发”并尽可能长时间地保持我们的系统尽可能简单。