在 DDD 项目上创建文件夹结构的更好方法是什么

Question

我的所有域驱动项目总是使用相同的文件夹结构：

entities
 - UserEntity.ts
 - OrgEntity.ts
repositories
 - UserRepo.ts
services
  - (and so on)

但我总是想知道这样组织项目是不是一个好方法，或者像这样的其他方式：

users
 - UserEntity.ts
 - UserRepo.ts
 - UserService.ts
orgs
 - (anything belongs to Org)

使用这两种方法有什么利弊和例子吗？或者关于什么应该是正确的、更好的方法的任何建议？

提前致谢，

Answer 1

第二种方法在我眼中（以及许多其他人眼中）更好。这个想法是每个目录/包都有彼此相关的文件，而不是因为层（至少在域中）。我使用的方法和看到其他人使用的方法也使用端口和适配器，与此类似：

- Domain Model
  - (Domain area: Application Service, Root aggregate, Repository interface, etc)
  - Users
    - All domain files related to users.
  - Common
    - Components common across multiple domain areas.
      If many components work together, I would put them in their own
      folder and given it a proper name.
- Adapters
  - Primary (triggers coming into the application)
    - (for example http controllers)
    - Users
      - GetUserController
      - (API DTOs)
  - Secondary (adapters going out of the service)
    - (for example repository implementations)
    - Users
      - UserRepository
      - (Any other supporting components).

一些注意事项：

• 我试图让域区域（不知道如何称呼它们）在它们之间没有依赖性。这有助于防止一次更改具有较大的爆炸半径。
• 我可能不会将适配器拆分为主要/次要的，但每个域区域仍然分开（因此主要和次要适配器都在一个文件夹中）

Answer 2

我将第一个变体称为 IKEA 结构：

• 有灯部
• 有一个椅子部
• 等等。

第二种更家的感觉风格，每个房间都可以有灯和椅子等家具。它更面向领域，因为每个领域部分（房间）都可以有这些方面（灯具和家具）。

对于更复杂的应用程序，您可以使用域优先变体，然后在每个域包中进一步构建结构，这样您就可以充分利用这两种变体：

user
- persistence
  - UserRepository.ts
  - UserEntity.ts
- service
  - UserService.ts
  - UserDTO.ts
  - NoSuchUserException.ts
org
- persistence
  - OrgRepository.ts
  - OrgEntity.ts
...

我通常更进一步（尽管使用 Java/Kotlin 而不是 Typescript），并在我的应用程序中为每个子域创建 submodules。这样，我可以将子模块作为一个应用程序（模块化单体）发布，或者如果我愿意，也可以将它们捆绑到单独的应用程序（微服务）。这也允许我启用并行构建，子模块可以在parallel中构建和测试，显着减少构建时间。

每个域之间的共享类（例如 BaseEntity）可以放入共享子模块（DDD：shared kernel）。