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

我会选择第二个选项，以便长寿命申请的可持续性。

让我用一个例子解释一下：

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

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

它可以节省大量时间，并且可以轻松实现IMO。

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

1 个答案: