Domain vs Entities model? Domain-Driven-Design (DDD)?

Aggregates ARE domain entities - domain entities that contain other entities, thereby modelling one or more conceptual relationships.

It is unfortunately a popular form of DDD. I say unfortunately because it completely ignores the core principles of DDD, that is the actual modeling of the problem.

Having pure data structures does nothing to tell the reader what is happening, what problems are being solved, it does not use the Ubiquitous Language, since getting/setting stuff is rarely if ever part of the problem.

If you just look at the repository's structure it seems the author went to great lengths to avoid mentioning anything relevant to the domain at hand. That is exactly the opposite of what should happen. At every turn you should be focused on using the exact terminology your business peers use.

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.