From https://www.golinuxcloud.com/hexagonal-architectural-golang/
-
Core Business Logic: This is the central component of the architecture, and it contains the application's core domain logic. This component should be independent of any external systems and should not be affected by changes in the infrastructure or the user interface.
-
Adapters: These are the components that connect the core business logic to the external systems. They can be thought of as the "ports" through which the application communicates with the outside world. Adapters can take many forms, including APIs, databases, user interfaces, and messaging systems.
a. Primary Adapter: This is the adapter that handles the application's primary input/output. For example, in a web application, the primary adapter might be an HTTP server that accepts incoming requests and returns responses. The primary adapter is responsible for translating incoming requests into domain-specific operations that can be processed by the core business logic, and translating the responses back into a format that can be understood by the requesting system.
b. Secondary Adapters: These are the adapters that handle the application's secondary input/output. They can be thought of as "plugins" that provide additional functionality to the application. For example, a secondary adapter might be a database adapter that stores data for the application.
-
Interfaces: These are the contracts that define the communication between the core business logic and the adapters. They ensure that the adapters provide the necessary functionality to the core business logic, and that the core business logic provides the necessary information to the adapters. Interfaces can be thought of as the "language" that the adapters and the core business logic use to communicate with each other.
-
Dependencies: These are the external libraries or services that the application depends on. They are managed by the adapters, and should not be directly accessed by the core business logic. This allows the core business logic to remain independent of any specific infrastructure or technology choices.
https://threedots.tech/post/ddd-cqrs-clean-architecture-combined/
https://threedots.tech/post/repository-pattern-in-go/
Current:
`--internal
| `--trainings
| | `--adapters
| | | `--trainings_firestore_repository.go
| | | `--trainings_firestore_repository_test.go
| | | `--users_grpc.go
| | | `--trainer_grpc.go
| | `--go.sum
| | `--app
| | | `--command
| | | | `--services.go
| | | | `--schedule_training.go
| | | | `--request_training_reschedule.go
| | | | `--approve_training_reschedule.go
| | | | `--cancel_training_test.go
| | | | `--cancel_training.go
| | | | `--reschedule_training.go
| | | | `--reject_training_reschedule.go
| | | `--query
| | | | `--types.go
| | | | `--all_trainings.go
| | | | `--trainings_for_user.go
| | | `--app.go
| | `--main.go
| | `--domain
| | | `--training
| | | | `--training.go
| | | | `--repository.go
| | | | `--cancel_test.go
| | | | `--user.go
| | | | `--cancel.go
| | | | `--reschedule_test.go
| | | | `--reschedule.go
| | | | `--user_test.go
| | | | `--training_test.go
| | | | `--cancel_balance.go
| | `--service
| | | `--service.go
| | | `--component_test.go
| | | `--mocks.go
| | `--ports
| | | `--openapi_types.gen.go
| | | `--openapi_api.gen.go
| | | `--http.go
Proposing:
└── internal
└── name of entity
├── interfaces
│ ├── adapters
│ ├── endpointA_memory_repository.go
│ ├── endpointA_mysql_repository.go
│ ├── endpointA_firestore_repository.go
│ ├── endpointA_repository_test.go
│ ├── endpointB_xxx.go
│ ├── postgres.go
│ └── redis.go
│ ├── ports (handlers)
│ ├── grpc.go
│ └── http.go
│ ├── services
└── application.go
│ └── repositories
│ ├── postgres.go
│ └── redis.go
└── core
├── app
├── command
├── query
└── app.go
└── domain/endpointA (the repository interface)
├── serviceAmodule1.go
├── serviceAmodule2.go
└── repository.go