how should I acess other context in this framework #38

[johnyanchen]

Excuse me, if I need to access other contexts, such as converting objects from other contexts into objects in this context, where should the definition of this object and the anti-corrosion layer interface declaration be placed in this framework

[sklinkert]

In DDD the anti-corruption layer (ACL) lives right at your Bounded-Context border. In Go you typically split it between:

If your core domain logic needs to “call out” into another context, define a port (interface) in your domain package. E.g.

// internal/domain/ports/external_user_port.go
package ports

type ExternalUserProvider interface {
  FetchUserByID(ctx context.Context, id uuid.UUID) (*ExternalUser, error)
}

This makes your domain depend only on the abstraction of “I need to get a user,” not on any transport or conversion details.

Adapter + DTO + mapper

Put your concrete HTTP/GRPC/DB client, the external‐context DTOs and the translation logic in infrastructure/adapter (if you want all I/O code isolated under internal/infrastructure)

e.g.

internal/infrastructure/externaluser/http_client.go        // implements ExternalUserProvider
internal/infrastructure/externaluser/dto.go                // ExternalUserRequest/Response
internal/infrastructure/externaluser/mapper.go             // dto ↔ domain ExternalUser

to summarise:

• Port (interface) goes in your domain (or a sub-pkg like domain/ports) if your entities or domain services call it.
• DTOs & mapping code live in application or infrastructure, depending on whether you see it as part of your use-case layer or pure I/O adapters.
• The ACL itself is the combination of that interface + adapter + mapper, cleanly decoupling your core model from the external system’s schema.