5

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

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>
    |____ ...

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

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

谢谢你。

4

1 回答 1

5

我会选择第二个选项，以延长应用程序的可维护性。

让我用一个例子来解释它：

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

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

它可以节省大量时间，并简化 IMO 的可维护性。

于 2010-11-10T17:31:35.553 回答