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

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的可持续性.