How to design an API wrapper by following Domain Driven design principles?

The question effectively is for any API wrapper with a domain object that has bulky operations on it. My use case has Files as the concrete object.

I am working on a creating an API wrapper and need some assistance with its design. The project revolves around files, and operations(edit/merge/convert) on it. I am reading about DDD and trying to bring that in my project. My goal is to write clean maintainable code, and I am having a tough time doing that.

File is the core object of my project, and operations like file edit, file merge will be the verbs that'll act on the file. I am thinking of having a file domain class with the verbs (edit, convert) as the functions inside the class. The problem is, all the file operations are async API calls which need different processing based on the call results. So if someone calls file edit, I'll invoke a backend API which'll take its own time. Writing all the API flow inside the File class makes it harder to read and maintain, especially with the error handling. I feel that I am not doing it right. How can I break it down into simpler pieces? I was thinking of adding another layer which manages the file operations, but not really sure how to proceed on that. The goal of this question is to know if I am thinking in the right direction in DDD aspects. Should the operations really be inside the file class or should they be invoked via another layer, especially if they're so bulky. Thanks!

I am referring this link for learning DDD concepts : https://lostechies.com/gabrielschenker/2015/05/07/ddd-special-scenarios-part-1/

If you downvote the question, please let me know how can I phrase it better, or should I even questions like this here. I've seen matching questions here, but none of them address my concern.