架构（结构）取向与面向特征的项目结构

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

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

让我用一个例子解释：

有一天，在应用发布后一年，和几个月谁又写道原代码球队已经离开后，用户检测并在一定的工艺报告bug 。该票肯定会看起来像“这东西不起作用”，在一些电子邮件乒乓后，它将最终成为“我不能为澳大利亚客户保存多产品订单”。

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

它可以节省大量的时间，并减轻IMO的可保持性。