面向架构（结构）与面向功能的项目结构

Question

我参与的项目有一个面向架构的项目文件/文件夹结构：

Root
|____ Node1
    |____ Event Handlers
    |         |___ <all event handlers of project>
    |____ Events
    |         |___ <all events of project>
    |____ Request Handlers  
    |         |___ <all request handlers of project>
    |____ Requests
    |         |___ <all requests of project>
    |____ ...

从系统架构的角度来看是一个清晰的（已由开发团队提出）。

它是设计团队提出的面向功能的结构：

Root
|____ Feature #1
    |____ Event Handlers
    |         |___ <all event handlers of Feature #1>
    |____ Events
    |         |___ <all events of Feature #1>
    |____ Request Handlers  
    |         |___ <all request handlers of Feature #1>
    |____ Requests
    |         |___ <all requests of Feature #1>
    |____ ...

这种变体更接近设计人员，并且清楚地描述了要实现的功能。

我们的团队已经开始了一场圣战：什么是最好的方法。 有人可以帮助我们解释第一个和第二个的缺点和优点吗？ 也许还有第三种对我们双方都更有用、更有利的方法。

谢谢。

Answer 1

我会选择第二个选项，以便实现长寿命应用的可维护性。

我举个例子来解释一下：

应用发布一年后的某一天，原代码编写团队离开几个月后，用户在某个流程中检测到并报告了错误。该票肯定会看起来像“这东西不起作用”，经过一些电子邮件乒乓球之后，它最终会变成“我无法为澳大利亚客户保存多产品订单”。

好吧，在第一个项目结构中，您必须在所有项目请求和事件处理程序中搜索有错误的代码所在。
在第二个模块中，您可以在订单保存模块（或根据您的结构粒度，“海外/多产品订单保存”模块）缩小搜索范围。

在我看来，它可以节省大量时间，并简化可维护性。