帐户交易和余额的抽象

Question

我们有10个应用程序更新帐户平衡表，没有记录信用/借方线交易(不确定原因)。它们都有几乎相同的SQL语句。为了摆脱这种结构，并记录事务，我们提出以下建议。是否有其他方法建议让设计更优化或更抽象，回顾最后一种方法？

电流结构：

10个应用程序->嵌入式SQL ->更新数据库平衡

更好的结构：

10个应用程序

最抽象的结构：

10个应用程序->服务层->(包括TransactionLine存储库

Answer 1

域

的快速概述

在会计的域名中，有以下不同但相关的概念：

• 账户确定要核算的基本财务“主题”；
• 事务或投递代表一个业务事件，它将值的多个更改聚合到帐户中；
• (过帐/交易)行或项目是交易的一部分，它记录了影响一个帐户的价值变化；
• 账户余额汇总一个账户的价值，同时考虑到所有相关项目；
• 分类账是按时间顺序排列的一组交易。总分类账是所有项目的集合，按账户按时间顺序排列。

除了基本的(以及这里有些简化的)概念之外，在所有情况下都有一些业务逻辑可以确保：

• 一笔交易的所有借方和贷方的总和必须相等(或者如果你用负数表示贷项，那么总数必须是0)。
• 因此，分类帐或总分类帐中所有借方的总和在机械上也是相等的。
• 总分类账中一个帐户的项目总数必须始终等于该帐户的余额。

分析您的设计方案

目前的方法对每个应用程序的质量都非常敏感。每个应用程序都可能打破规则，在所有其他应用程序的帐户中造成混乱。

Linq方法确保了所有应用程序之间的更好的一致性。但是，您确定可以保证所有新域对象的一致更新，特别是如果您要更新一个应用程序而忘记重新编译/部署其他应用程序的话？

更抽象的方法似乎有一个更干净的架构。此外，它还实现了一个健全的分离关注点：

• 这10个应用程序各自实现各自的专用应用逻辑(销售、采购、库存管理等)。
• 会计的公共领域逻辑由您的会计服务层保证。如果您对服务层进行了彻底的测试，那么您就可以确保没有任何应用程序会破坏帐户(如果它是某个人忘记重新编译的应用程序的旧版本的话)。在每个应用程序中，开发人员只需担心正确的事务会被记录下来，并且只会将测试集中在应用程序的专门逻辑上，而不必理解会计的细节。
• 如果您想要改进您的会计逻辑，例如添加一些日志功能(例如，应财务审计师的请求)，您只需在您的服务级别上这样做，并且您确信所有应用程序都将按照预期的方式处理新特性。

因此，最终，应用程序不应该再做任何会计计算:它们应该只是查询服务以获取要使用的帐户，将一致的事务发送到服务(使用某种DTO)，并在需要时查询帐户余额。