作为Ruby on Rails开发人员，在设计/实现Web应用程序时，我将问题域中的基本概念/实体作为模型来实现。通常，这些类是从基类ORM类派生的类（例如ActiveRecord::Base），它们映射来自数据库表的记录并添加包含实现与该模型相关的业务逻辑的额外方法。Clojure中的MVC模型
这种方法的优点是，您可以快速找到与问题域中的对象有关的所有业务逻辑，以便如果模型类不是很大，则可以有效地理解应用程序的该部分的工作方式。它也从所有的表示逻辑中分离出来。此外，由于ORM，业务逻辑方法包含很少的DB特定的代码，因此非常干净且易于阅读。
缺点是这些类通常增长到一个庞大的规模，因此难以理解为一个整体。
所以我的问题是：
一个Clojure的发展背后的驱动理念的是separate complex things到是合理的，并把数据作为数据，从而避免数据相结合和分离value state and identity最大程度。
Clojure生态系统是否提供了一些与OOP的ORM具有类似功能的库？ 希望用纯函数处理数据，将一个数据结构转换为另一个数据结构会导致一些clojure程序员回避ORMs，尽管存在没有理由如果您真的想要在Clojure中使用Hibernate，请使用。
什么是“Clojure方式”来组织这样的代码？ 我喜欢Amit Rathore's presentation of the topic
简单地说，你不要在一个对象包装的东西，你与像列表，集合和地图数据结构直接进行编程。因此，完成了ORM的工作简化为将一个数据结构转换为另一个数据结构：例如，user-row->user-record函数可能会将您从SQL数据库弹出的值列表转换为表示应用业务逻辑中的用户的映射。当你保存用户时，你必须调用一个反向函数。
我不得不说，对于一个经验丰富的OOP程序员来说，确实很难得到一个事实，即围绕着东西的仪式少得多。我们的大脑似乎对抗了这个想法 - 恕我直言，因为它对于一个有经验的开发人员/软件架构师似乎太简单和不成熟。 :-)我希望我能写出更多复杂的回应，充满奇怪的词语，听起来像一个真正的专家，但我实际上不能，因为没有更多的补充。 :-)
顺便说一句，一个小而有趣的观点 - 数据结构的普遍使用是在OOP世界中被认为是错误的做法。例如，你不应该将钱储存在一个简单的元组[10, "USD"]中，而是写出完整的public class Money来封装所有的货币，比较，舍入等。但是编写元组正是我们在FP中所做的。我记得我对这个来自OOP世界的奇怪感觉。
当谈到组织代码或多或少时，与命名空间方面相同的规则与OOP相同。除了所有函数（您用于调用方法的函数）现在都是无状态的，并且通常将上述用户记录作为参数之外，您可以像在java包中那样基于主题组织代码。因此，代替foo.barChange()，您将拥有(bar foo)，其中纯函数bar将返回新数据结构foo2而不是修改foo的状态。
话虽这么说的OOP的好处之一是，不仅有已经使用这种模式编写的许多应用程序，但更重要的是一直存在多个代的方法尝试了（这是我们得到了喜欢的东西DI容器今天的流行等）。函数式编程还没有。基本上没有人有关于如何在FP中执行应用程序体系结构的最终手册。顺便说一下，这就是为什么人们通常不愿意编写大型框架，并鼓励继续使用数据转换功能。这样，你总是可以按照你想要的方式将它连接起来，避免出现建筑缺陷。