Question

我正在寻找一个描述设计模式（或反模式）的术语，它描述了系统何时按概括而不是业务条款组织。

例如，考虑以下域驱动的示例：

Customer.Load
Account.Load
Orders.Load

VS

Load.LoadCustomers
Load.LoadAccounts
Load.LoadOrders

另一个例子可以在mvc中看到： ASP.NET MVC - putting controller & associated views in the same folder?

虽然更多关于组织与设计，但来自pettys IMO的评论是正确的：

意识到系统存在两个维度，即：建筑和业务。原始海报想要保留所有在一个地方处理某个商业问题的部分。该默认的ASP.NET MVC布局完全解决了单个业务问题有点让建筑类似的类可以保持在一起。在这两个选择之间，我宁愿按业务分组关注而不是建筑关注

只有一种方法来物理组织项目。 OP要求按域组织，并且pettys将默认组织描述为“架构上”有组织的。但正是这个“建筑”组织，我最好尝试分类。

在我看来，这是面向方面的设计，即设计有利于对一般流程而不是特定业务术语的分类。我不打算将这与面向方面的编程混淆，后者可以补充DDD，但令人困惑，这就是为什么我想知道是否有更好的名称。

Answer 1

有许多可以组织系统的概括。据我所知，大约在2003年发布DDD时，有一些时尚流行。

表驱动或数据驱动设计，通常意味着从一组特定的关系数据中获取实现。
模型驱动设计，通常意味着从UML图中推导出您的实现。
配置驱动设计，通常意味着将尽可能多的实现转换为XML文件。

我确信还有更多，你可以说所有这些都更多地关注系统的架构而不是域。回想起来，你可以认为它们中的一些或全部都是反模式。用尼尔福特的话说，

今天的最佳做法是明天的反模式。

参考：https://visualstudiomagazine.com/articles/2015/07/01/domain-driven-design.aspx

Answer 2

在有人投票并意识到这里可能有答案之后，我被提示回去阅读。

从https://en.wikipedia.org/wiki/Anti-pattern#Software_design起，我一半定居于BaseBean。但是，@ djvuk在评论中提到“过程编程”。我认为他可能遇到了麻烦-这里的反模式可以描述为过程或函数驱动的-即使其中应用代码的域完全不同，但包含代码的过程或生命周期是相同的。例如，模型，视图，控制器提供了相同的通用功能或过程，即使它们是为完全不同的域创建的。

现在这样说，很明显，至少在MVC的情况下，模式正在影响甚至泄漏到设计中，而不是相反。模式是DDD或功能驱动的对象遵循的模式，但它不一定是设计的一部分。

我将在此处提交两个可能的反模式名称：

功能驱动设计
模式驱动设计

域驱动设计的反义词是什么？

2 个答案: