Question: I'm trying to create a nice a Solution structure for a new DDD project. I Created a "Core" project, where I added the Entities, ValueObjects and the repositories Interfaces then I added an "Infrastructure" project that contains the implementation of the previous IRepository.

Now, since my db will be MongoDb I need to add the attributes like "[BsonDateTimeOptions]" in some of the fields of the Entities, this will require to add a reference to the MongoDb driver package in the core project.

Since the core project should not contains any reference to MongoDb, should only contains business logic and it should be reusable in any other project (mobile - Xamarin) what should be the best practice in this situation?

What I'm able to think is:

* the entities will not contains any reference to MongoDb
* create in the Infrastructure projects a model for each Entity, that is a copy of the related entity but with the MongoDb attributes.
* create a layer (in the repository?) that is able to use the model to query in the db, then transform it in entity and so returning the Entity, hiding inside the repository the model object.

This approach has a problem, that I will have a copy of the entity, the model, which only has the MongoDb attributes, and when adding some fields to an entity, I will have to modify the model too. Is this the correct approach?

Everything started from [this](https://github.com/ardalis/CleanArchitecture) solution structure.

Answer: 
*Note: I don't use C# but this works in PHP and maybe it helps you*

They way I do it is to create the Aggregate root, nested entities and Value objects as plain objects (data + behavior, without any dependency to infrastructure/technology). Then, when persisting/rehydrating I use reflection to store/load the Aggregates from the Repository. The Repository is mapping any known domain objects to infrastructure objects. For example, the primitive types (string, bool, int, float, null) are stored without any transformation. The [Date](http://php.net/manual/ro/class.datetimeimmutable.php) is transformed to [ISODate](https://docs.mongodb.com/manual/reference/bson-types/#document-bson-type-date), the Guid is transformed to [ObjectId](https://docs.mongodb.com/manual/reference/method/ObjectId/) and so on.

This is possible because of reflection and easy because MongoDB is storing objects as JSON and there is little (or none) impedance mismatch.
Yes, the approach you describe is correct, but what you call a layer in repo, would be just an adapter in the infrastructure layer. The adapter implements the repo interface using mongodb technology, and use a mapper to convert between the two models. The mapper belongs to the infraestructure layer too.