I see this as strict separation between the domain model and the persistence model. By duplicating this model, it becomes possible to fine-tune models for their specific purpose. One represents business rules, other is easy to persist and query. If it was just single model, it would be necessary to make tradeoff-s between the two.
This is specific way to implement DDD. In plain DDD, there is nothing that talks about how the domain entities should be persisted. It is considered a secondary concern. In DDD, you would only think about the domain entities and how those entities are persisted is decided elsewhere.
But in case of this specific implementation, I find there is one thing incorrect. In DDD, the repositories are part of the domain model itself. That means that the repository should work with domain entities, not persistence entities. But that is what is happening here. Transformation from domain to persistence entities happens in services, which is wrong place to do it. It should happen inside the repositories. This way, it becomes implementation detail of a repository. This way it is irrelevant to the user of the repository if the repository is using EF, plain SQL or something different to actually persist the data.
Example of the above is in /src/Frameworks/Transaction/Services/TransactionService.cs in method
CreateTransactionAndUpdateSummary (using AutoMapper):
// transform domain entity to persistence entity
var accountTransactionEntity = _mapper.Map<AccountTransactionEntity>(accountTransaction);
var accountSummaryEntity = _mapper.Map<AccountSummaryEntity>(accountSummary);
// call repository with persistence entities
await _accountTransactionRepository.Create(accountTransactionEntity, accountSummaryEntity);
var currentSummary = await _accountSummaryRepository.Read(accountTransaction.AccountNumber);
// transform persistence entity to domain entity
var result = _mapper.Map<TransactionResult>(accountTransactionEntity);
The above code should be inside the repository itself, not in the service.