0

在具有如下文件夹结构的 PHP DDD 应用程序中：

应用程序/
    意见/
    控制器/
    领域/
        模型/（orm生成）           
        服务/
        工厂/

以下类代表什么（从 DDD 术语的角度来看）以及它们的推荐位置是什么。

  • 字典（基本功能：检查单词是否有效）
  • HtmlValidator（基本功能：检查字符串是否是有效的 html）
  • UserCollection（基本功能：对用户集合的操作）

    • 4

    2 回答 2

    5

    这看起来不像 DDD 应用程序。

    特别是，ORM 生成的模型不是领域模型。这是一件好事，如果您的应用程序核心价值在于数据并且您只需要处理 CRUD 操作。

    在 DDD 中，应用程序模型来自领域专家的语言，即了解您的应用程序所针对的业务的人，因为这是他自己的工作，但对技术一无所知。

    如果您的领域专家谈论字典和 UserCollection（很奇怪，顺便说一句），那么这些类实际上是模型。HtmlValidator，几乎按照定义，不是一个商业术语。

    如果您的应用程序的价值来自技术组件，我建议您避免使用 DDD 技术。仅将 DDD 用于处理非常复杂的业务规则的应用程序。

    编辑
    大多数时候域模型值得（至少）一个单独的模块。在 PHP 中，我建议您将其捆绑在（至少）一个单独的包中。但是，使用 MVC 模式并不意味着使用 DDD：您可以将 MVC 用于数据驱动的应用程序，这很好。在这种情况下，我只会在模型中放入 ORM 生成的类。在这种情况下，我会将所有这些类放在一个 controllers/lib 文件夹中。

    于 2013-03-30T12:36:07.303 回答
    2

    结构还不错，但我会将模型重命名为实体，因为在 MVC 中，模型由服务、实体和其他类型的类组成。

    Dictionary 和 HtmlValidator 没有身份并且是无状态的，这意味着它们属于服务。

    app/
    views/
    controllers/
    domain/
        entities/ ( orm generated )           
        services/  (HtmlValidator)
        factories/

    尽管它看起来像一个非常简单的应用程序，但这确实意味着您不应该开始使用 DDD 构建块。每个应用程序都会随着时间的推移而增长，最好从适当的结构开始，以避免以后需要对其进行重构。

    我接下来你应该考虑创建某种模块，这样你就可以分离逻辑部分。您也可以将应用程序和表示层与域和基础设施层分开：

    app/
    views/
    controllers/
domain/
    module1     
        entities/           
        services/ 
        factories/ 
   module2 
        ....
vendor/  (infrastructure layer)
    ORM
    ... (some other 3rd party libs)
    于 2013-04-03T09:00:47.743 回答