ruby - 什么是贷款发放系统的良好模式设计？

Question

我正在设计一个贷款发放系统，该系统允许用户创建贷款，根据贷款产品参数制定贷款的还款时间表。我还应该能够增加罚款、费用等。重新安排贷款应该是可能的。我还需要一个贷款时间表来进行快速报告。

我有贷款表、贷款产品表、付款时间表和贷款历史表等。我无法理解如何提前设计此架构以防止其发生太大变化。

我在 ruby​​、rails3 和 datamapper 中这样做。

Answer 1

除了在最严格指定的应用程序中，我不确定您是否可以设计一个不会有太大变化的模式。您可以做的是制作不易碎的模式，允许发生变化的模式。在大多数情况下，这意味着。

1. 仅包含您知道满足当今要求所需的数据
2. 规范化。
3. 编写自动化测试。

第一条规则类似于“尽可能做最简单的事情”或“你不需要它”，程序员用来避免代码膨胀的规则。较小的模式，如较小的代码库，需要较少的更改工作。第二个(规范化)类似于不要重复自己 (DRY) 原则，也称为“一次且仅一次”，这是另一条用于降低代码更改成本的规则。第三条规则(测试)是程序员如何在不担心破坏一切的情况下使重构成为可能。通过测试，我的意思是测试使用模式的代码，但也测试模式本身:触发器、规则、级联删除等。可以测试，并且在测试时，更容易更改它们以响应不断变化的需求。

在数据库世界中，打破这些规则是有借口的。打破规则 1(做最简单的事情/YAGNI)的原因是，有些数据从一开始就更容易收集，但如果您决定以后确实需要它，就很难收集甚至不可能收集。尽管如此，在屈服于这个借口之前请三思。您几乎总是可以毫不费力地处理因稍后添加列或表而导致的数据间隙，但如果您包含今天可能只需要明天的数据，那么每次更改模式时都会为此付出代价。您包含的每一位最终不需要的数据都只是成本，没有任何好处。也许更重要的是，额外的数据会对性能产生可怕的影响，因为它会减少内存中可以容纳的记录数。尽管数据库在从磁盘读取时付出了巨大的努力来提供良好的性能，但它们的最佳性能来自于拥有足够的内存(或足够少的数据)，以便所有或大部分工作集都适合 RAM。

违反规则 2(规范化)的借口是性能:“数据仓库”应用程序有时需要非规范化，以防多表连接使数据库变慢和不稳定。我想确定在非规范化之前它是必需的，因为它不是免费的:数据存在于不止一次的地方使得模式更难以更改，并且在插入和更新时以查询速度换取更多工作。

我不知道违反规则 3(测试)的借口，或者至少不是一个好的借口，但这并不意味着没有。

Martin Fowler 写道 "Evolutionary Database Design" . Scott Amber 和 Pramod Sadalage 有一本关于 Refactoring Databases 的书.另见 a summary/cheat sheet of the book's refactorings .