我使用Rust将近一年了，我写了大约2万行代码（CLI、WebAssembly应用、Web服务器......）。
在我看来，编程范式的演变是朝着越来越大的设施去操作代表领域概念的结构。
例如，一个Java应用程序可以从UML图中设计出来，这使得它可以从实现的细节中抽象出来。
但即使在这个模型的具体实现中，我们仍然在操纵代表我们原始图的数据的类和对象，这非常令人愉快。
不过，我对Rust却没有这种感觉。因为它没有继承、抽象类...。
我对Rust的感觉是，我不得不制定一些实现策略，这些策略不断地使我与我的应用程序的心理模型保持距离，特别是由于所有权系统的原因。
例如，当你设计你的系统时，有一些概念与其他概念相关是很常见的，这最终会产生一个关联图结构。
但是Rust不鼓励在代码中复制这样的结构，除非你最后到处都是Rc<RefCell<T>>。
如果最后模型虽然适应了Rust的限制，却产生了一个远离领域概念的实现。
所以我想知道：是Rust从根本上不适合基于模型的方法（领域驱动设计），还是建模工具和方法不适合Rust？
PS：Rust是一种很好的语言，所有权系统是一个高性能和安全的应用程序的必要成本。我只是想知道Rust是否适用于基于模型的方法。
回答：
1、如果你想要一个无约束的图，那么Rust就会和你对抗，是的。一个任意的图有一个极其不明确的所有权层次结构。
但Rust非常擅长的是使用结构、枚举和特征进行分层建模。
- 如果两件东西通过成为一个整体的一部分而联系在一起，那么这个整体就是一个以部分为域的结构。
- 如果两个事物是一个更广泛的类别中相互排斥的种类，那么这个类别就是枚举，这些事物就是变体。
- 如果两个事物通常是不同的，但有一些相似之处，那么你可以用一个trait来表示这些相似之处。
- 而如果两个事物是不同的，不能互换，你可以使用newtype包装器来防止误用。
关于使用代数数据类型进行领域建模的一个很好的讲座是Scott Wlaschin讨论F中的建模，其中没有涉及Rust traits，但在其他方面非常有帮助。
2、如果你的领域对象（DDD中的聚合体？）是一个循环图，那么你就已经搞砸了。DDD和Rust都会希望你使用某种ID来指代外部聚合体/对象。
OOP代码库之所以经常会出现这样无形的混乱，部分原因在于它很容易忽略所有权层次，并创造出一个泥球，在这个泥球中，所有东西都或多或少地直接引用到其他东西。
因此，根据我的经验，对领域进行建模并不是问题所在。恰恰相反。有问题的是虚拟调度的模板，例如，跨越多个存储更新的数据库事务。