Domain Driven Design diagram for Umbrella app

Questions / Help
14

Pardon my ignorance but is there a technical reason for for adopting this type of organization:

inventory
        ├── authorizers
        │   ├── collection_authorizer.ex
        │   ├── permalink_authorizer.ex
        │   ├── variant_authorizer.ex
        │   └── product_authorizer.ex
        ├── models
        │   ├── collection.ex
        │   ├── image.ex
        │   ├── permalink.ex
        │   ├── price.ex
        │   ├── product.ex
        │   ├── stock.ex
        │   └── variant.ex
        ├── repositories
        │   ├── collection_repository.ex
        │   ├── permalink_repository.ex
        │   ├── variant_repository.ex
        │   └── product_repository.ex
        ├── uploaders
        │   └── image_uploader.ex
        ├── collection_service.ex
        │── permalink_service.ex
        │── variant_service.ex
        └── product_service.ex

rather than something like this

inventory
        ├── collection_service
        │   ├── collection.ex
        │   ├── collection_authorizer.ex
        │   ├── collection_repository.ex
        │   └── collection_service.ex
        │── permalink_service
        │   ├── permalink.ex
        │   ├── permalink_authorizer.ex
        │   ├── variant_repository.ex
        │   └── permalink_service.ex
        │── variant_service
        │   ├── variant.ex
        │   ├── variant_authorizer.ex
        │   ├── variant_repository.ex
        │   └── variant_service.ex
        └── product_service
            ├── product.ex
            ├── product_authorizer.ex
            ├── product_repository.ex
            └── product_service.ex

Seems the organizing principle is to put “like” things into the same place rather than “putting everything to deal with subject area X” into the same place. One of the starting points described by the article that I linked to earlier - Bring clarity to your monolith with Bounded Contexts - is to “Invert folder structures into a flat domain-oriented grouping”.

The organizing principle of “putting like things into the same place” that ultimately is responsible for “a Rails app always looking like a Rails app” (and not communicating the actual intent behind the web app) is what inspired Architecture: The Lost Years (Ruby Midwest 2011 Keynote). That type of organization is rarely helpful in revealing the emerging (context) boundaries as the application matures (Evans, DDD p.48: “…crucial discoveries always emerge during the design/implementation effort”).

FYI: for anyone interested: Eric Evans: DDD Reference (PDF 2011)

9 Likes