The best project structure for a Golang Domain-Driven Design (DDD) project will depend on the specific requirements of the project and the team working on it. However, a common structure that many teams find useful is to organize the project by package, where each package represents a different domain or subdomain of the system.
Here is a suggested structure:
**cmd**package for the main entry points of the application**internal**package for the private implementation of the application**pkg**package for the public interface of the application**internal/app**package for the application logic**internal/domain**package for the domain models and services**internal/infrastructure**package for the persistence and other infrastructure concerns
A common practice is to place entities in a package called “domain” or “entities” within the project’s root directory. Within that package, you can create subpackages to group related entities. For example, you could have a subpackage for “users” if you have entities related to users in your system, or a subpackage for “orders” if you have entities related to orders.
So… where should i place me entities?
DEPENDENCY / IMPORTS
Dependency relation:
The application layer should only depend on the domain layer, and the infrastructure layer should only depend on the application layer.
projectcmdinternalpkginternal/appimports domain package
internal/domaininternal/infrastructureimports application package
ENTITY DEFINITION
Here’s an example of a package structure for entities:
projectcmdinternalpkginternal/appinternal/domainentitiesuserorderproduct
internal/infrastructure
## INTERFACES DEFINITION
what about my interfaces? Interfaces are very important to design a decoupled system in Golang.
Here’s an example of a package structure for interfaces:
- `project`
- `cmd`
- `internal`
- `pkg`
- `internal/app`
- `interfaces`
- `user`
- `order`
- `product`
- `internal/domain`
- `internal/infrastructure`