域服务结构

Question

目前，我正在处理按其动作类型放置我的服务的问题，如

• App
  • 服务
    • 存储
    • 支付
      • 提供者
      • 出入口
      • IpnHandler

但我觉得，每当我们的支付提供商增长，我就必须检查Gateways / IpnHandler。我觉得支付网关应该只关心支付及其结果。但是我对这个结构不太满意，所以下一个选择出现在我的脑海中是这样。

• App
  • 服务
    • 存储
    • 支付
      • 贝宝
        • 网关
        • IpnHandler

那么，我们应该如何构造它们的文件夹呢？

Answer 1

去年圣诞节，我写了一篇叫做"快乐包装“的文章(也适用于这个节日季节)。

在这篇文章中，我详细介绍了三个简单的规则，以使包组织起来，能够找到东西，并保持它的可维护性，即尽可能地使更改本地化：

1. 包不应依赖于子包。
2. 子包不应该引入新的概念，而只是更多的细节。
3. 包应该反映业务--概念，而不是技术概念。

在你的例子中，第三条规则确实被打破了。你组织每项技术，并将属于逻辑上的东西分开。因此，我的建议是:摆脱包结构中的所有技术概念，专注于业务逻辑，让“业务”支配结构。