Domain-Driven Design shared Entity

I'm just starting my professional journey with Domain-Driven Design. I have a problem with the model of my classes. Below is a simplified class diagram.

I have two bounded contexts: Population and Issues.

Person is created with at least one document. Person can report a new Issue attaching multiple IssueAttachment.

I want to centralize files storage as a single File entity that I will persist in the single database table. The reason for centralization is the implementation of common actions before persistence, such as data compression or obtaining md5 hash. Also, storing all files in a single table simplifies testing data dumping process as I have to ignore just a single table to exclude heavy blobs.

However, after reading many articles, I can conclude that sharing entities between various contexts is not recommended.

Could you give me some design advice on how to deal with such a problem?

If you have already identified the two bounded context its great. Refer to following figure to understand from top view.

Now if we look each of these bounded context. In this case taking an example of onion architecture as you can see in figure2. (You can choose any architecture which fits your need).

Yes, you have heard right. Its indeed true the models in two different bounded context is different. For the moment you may see same class with same properties. But since they are in different bounded context they carry different meaning for the business. May be give it a shot to think in the following described way once you fill the gap between your infra to domain. Possibly you will see different meaning.

However in your case, your concern with sharing the same infra(ex: Filesystem) can be handled at the outer most layer of bounded context without worrying or mixing with your domain business.

As seen from figure-2 use the infra-layer which is in the outer most layer of the shell to interact with shared infra (Ex: Filesystem). Now in the domain (population or issue context respectively) define an interface which defines the respective business need. Which you can implement in application layer, from where you can interact with your infra-layer (of same bounded context). In turn you will be able to communicate with shared infrastructure (filesystem).

It does not matter tomorrow which infra you are going to use and what ever changes in the infra your domain business remains intact of it. So in this way you can keep things isolated. And in infra-layer with very less change and having some sort of mapper or adapter you will be able make the magical interaction with shared-infrastructure (filesystem).

Let me know your thought.