0

I have a domain entity with the saveToFile method. This method takes an implementation of the ToFileSavable interface. And now a few questions. What is this interface in DDD? Is it a port and its impementation are adapters? In what layers should these 2 elements be placed? How does this relate to domain services?

Sampeteq
  • 123
  • 8

1 Answers1

3

First of all, saving or persisting a domain entity is the responsibility of the repository, and the domain entity itself shouldn't be aware of whether you saved it or not.

for example, you have a Customer entity and you are implementing "updateEmail" use case, this would go as follows

-Application Layer
  -> UpdateCustomerEmailUseCase (CustomerRepositoryContract customerRepo)

->Domain Layer
  --> Customer

->Infrastructure Layer
   -> CustomerRepository implements CustomerRepositoryContract

UserRepositoryContract: has an abstract getById and save methods.

UpdateCustomerEmailUseCase: The use case responsibility, in general, is to orchestrate the high-level business logic, such as getting the User from the repository, then calling the "updateEmail" method in the Customer entity, then saving the customer in the repository.

Customer: Customer domain entity that has updateEmail, here you need to apply the business rules and invariants.

CustomerRepository: an implementation of the CustomerRepositoryContract that only know how to save the customer whether in a DB or file.

What is this interface in DDD? Is it a port and its impementation are adapters?

A port is an entry point, provided by the core logic. It defines a set of functions which in this case the CustomerRepositoryContract

An adapter is a bridge between the application and the service that is needed by the application. It fits a specific port which in this case CustomerRepository

How does this relate to domain services?

Domain services carry domain knowledge that doesn’t naturally fit entities and value objects. as you notice we didn't use any domain service here since the domain logic fitted in our Customer entity.

As an example of a domain service implementation, if you're implementing a "changePassword" use case and one of the business requirements is to encrypt that password, the encryption logic won't fit in the User entity and you would need EncryptionService that holds that logic, the application layer (ChangePassUseCase) then will call the service to encrypt the password, then call changePass in the domain entity, finally save it in the repository.

Look here for more info: https://enterprisecraftsmanship.com/posts/domain-vs-application-services/

I hope this answered your question

Hassan Ibrahem
  • 51
  • 7