Implement DDD Inspired Folder Structure

[tn3rb]

To keep things better organized I would like to follow a Domain Driven Design (DDD) / Onion Architecture inspired folder layout.

The primary layers are as follows:

infrastructure

• outermost layer
• connects app to outside world - APIs, database, services, etc
• provides adapters for external services

application

• middle layer
• coordinates access to business logic
• global entities, value objects, and services

domain

• innermost layer
• business logic use cases

Here's the full structure:

/application
    /config
    /controllers
        /event-editor
    /entities
    /services
    /ui
        /components
            /display
            /forms
            /layout
        /web
            /event-editor
    /value-objects

/domain
    /event-editor
        /entities
        /interfaces
        /services

/infrastructure
    /adapters
    /config
    /DAOs
    /services

/tests

PLZ NOTE: everything previously in the src folder has been moved into the ZZZ folder

Further Points to Consider

The most important thing to take away from the above structure is that the bulk of the logic should ultimately be grouped into specific "domains" also called "bounded contexts" in DDD. A "bounded context" essentially means a group of interrelated parts and/or processes with clearly defined edges. An example might be an "admin context" or "admin domain", which would be composed of everything related to the admin side of an application (domains can also be nested).

For the EDTR, I have added /assets/src/domain/event-editor as a starting point, but you will notice that there is also an /assets/src/application/controllers/event-editor folder as well as an /assets/src/application/ui/web/event-editor folder. I'm not sure yet whether we will want or need these. Ideally, the /assets/src/domain folder is reserved just for core business logic that can then be accessed accordingly based on the current request type (api, cli, rss, web, etc)(i know some of these don't apply to our use case atm).

The idea behind /assets/src/application/controllers/ is for any logic required for routing requests to the appropriate domain and ui elements, the latter of which would be located in the corresponding /assets/src/application/ui folder for the request type. It's possible that we won't require any kind of routing as that will be handled totally on the PHP side of things where the requests get handled initially.

Some developers like to place all of their UI related logic in a separate presentation layer in the root of their applications to keep things separated even more like:

• application
• domain
• infrastructure
• presentation (or ui)

which we may want to do as well, depending on how crowded we expect things to get.

For the infrastructure layer I currently just have some generic folders for putting things in, but some devs like to also separate logic here based on the infrastructure type in a manner similar to the "bounded contexts" in the domain layer. So for example, you might have folders like

• application
  • persistence
    • ORM (database, etc)
    • other file storage
  • security
  • logging
  • message APIs
    • email
    • sms
    • twitter
  • payment gateways
  • other external APIs

so we might also want to do something like this as well.

Last point I want to make is that the above proposed structure is not set and stone and may be different than other things you have seen regarding DDD (if you've even read about if before). Lots of DDD proponents organize things completely differently and there is little consensus about even how the various layers are stacked, for example, the application layer is often considered the outermost layer and the infrastructure layer can be the innermost or sometimes as a layer that runs perpendicular to the others. Ultimately it just has to make sense and work for us.

[manzoorwanijk]

Great! 👍