Question: In this github, <https://github.com/johnph/simple-transaction>, under the `Transaction.Framework` project, there are entities (located at Data/Entities)

* AccountSummaryEntity.cs
* AccountTransactionEntity

and in the domain folder, there are domain model:

* AccountSummary.cs
* AccountTransaction.cs
* TransactionResult.cs

From what I observed, the entities are mainly used for repositories while the domain model is used for almost everything else like business logic validation. Is this known as domain-driven-design?

Answer: 
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](https://github.com/johnph/simple-transaction/tree/master/src/Frameworks/Transaction) 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.
Aggregates ARE domain entities - domain entities that contain other entities, thereby modelling one or more conceptual relationships.