决定如何使用If块拆分体系结构

Question

如果对不同的体系结构进行块检查，我很难决定处理拆分的最佳方法。我可能完全错误地处理了这个场景，所以如果是这样，或者这是重复的，请告诉我。

作为一个简单的例子，假设我们为一个web脚本考虑两个参数:成员状态(非成员、成员类型-A、类型-B、类型-C)和表单提交/非表单提交。表格可由会员及非会员提交.目前，理想情况下，脚本将按如下方式分开：

Members (A, B, C)
    ->Non-Forms
    ->Forms
Non-Members
    ->Non-Forms
    ->Forms

...however，它可以用另一种方式设置：

Forms
    ->Members
    ->Non-Members
Non-Forms
    ->Members
    ->Non-Members

我想这是一个特殊的情况，所以我们会考虑为什么你可能会或可能不想在其他任务之前处理表单等等。然而，我正在寻找未来决定这种架构划分方案的一般标准，而不是考虑特殊情况，而不是明显的考虑因素，这样我就可以自己解决了。(注:当然，在这种情况下，安全性是一个考虑因素，因此有很好的理由将成员和非会员功能分开，这是我可能会认为是一个“明显的考虑”。如果你想为这个案子添加什么，我会全神贯注的。)

Answer 1

为这个实例设计软件的最好方法是通过域模型驱动的方法。本质上设计您的域模型和域模型中实体之间的关系。持久性、事件、业务逻辑、安全性、视图和控制器逻辑都可以在事后确定。

示例：

• 提交:表单和非表单之间的共同属性
• 个人？：成员和非成员之间的共同属性。
• 表单:扩展提交，具有引用人、属性的表单。
• 非形式:扩展提交，具有对人的引用，属性为非表单。
• 成员:扩展成员的个人、属性
• 非会员:扩展非会员的人、属性

既然您已经定义了域模型和它们之间的关系，那么考虑您的设计的其他方面就成为了逻辑的下一步。什么是明确定义的行为，一个非形式之上的形式？在代码中定义这些行为。在提交表单时，应该执行什么业务逻辑？编码它。当然，安全性是根深蒂固的，您可以将成员和非成员之间的不同行为视为业务逻辑的一部分。当然，不要忘记彻底地对所有应用程序行为进行单元测试。

在您的设计中最重要的是定义您的域模型，只有这样您才应该考虑行为。