project-organization - 面向架构(结构)与面向功能的项目结构

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

为了实现长生命周期应用程序的可维护性，我会选择第二个选项。

让我用一个例子来解释一下:

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

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

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