Is it fine to use my domain model as DTO (Entity Framework Core)? I was reading about anemic data models and rich domain models in DDD. I don't want to follow DDD completely but take rather pragmatic approach and just take some concepts out of it because clean ddd seems like an overkill. What I'm building is Web API (using ASP.NET Core and Entity Framework Core). 

I don't want to maintain separate DTOs just for serializing and deserializing my models.

And I want to make most of the things like service layer and my controllers generic. Because it's mostly CRUD and logic is repeating - a lot of boilerplate.

I'm not planning to use any other ORM other than EF Core. 

EF Core allows mapping to backing fields:

https://ardalis.com/encapsulated-collections-in-entity-framework-core
https://technet.microsoft.com/en-us/mt842503.aspx

Is it fine if I will design my models like this and at the same time use them as my DTOs for serialization and deserialization?

public class Player
{
    [JsonIgnore]
    public int Id { get; set; }

    [NotMapped, Required]
    public PlayerInfo ActiveInfo { get; set; } // setter must be public to allow deserialization (or use custom resolver for json net)

    [JsonIgnore]
    public ICollection&lt;PlayerInfo&gt; PlayerInfos { get; set; } = new HashSet&lt;PlayerInfo&gt;();

    private Player()
    {
    }

    public Player(PlayerInfo info)
    {
        info.IsActive = true;
        PlayerInfos.Add(info);
    }

    public void SetActiveInfo(PlayerInfo playerInfo)
    {
        var currentlyActiveInfo = PlayerInfos.SingleOrDefault(info =&gt; info.IsActive);
        if (currentlyActiveInfo != null)
        {
            currentlyActiveInfo.IsActive = false;
        }
        playerInfo.IsActive = true;
        PlayerInfos.Add(playerInfo);

        ActiveInfo = playerInfo;
    }
}


This is controller:

public class PlayerController
{
    private readonly DbContext _dbContext { get; set; }
    private readonly DbSet&lt;Player&gt; _players { get; set; }

    public PlayerController(DbContext dbContext)
    {
        _dbContext = dbContext;
        _players = dbContext.Set&lt;Player&gt;();
    }

    // Create new player
    [HttpPost]
    public ActionResult&lt;Player&gt; Post([FromBody] Player player)
    {
        if (!ModelState.IsValid)
        {
           //Handle validation error
        }
        // No service layer for the sake of simplicity.
        player.SetActiveInfo(player.ActiveInfo); // will use _activeInfo
        _players.Add(player); // begins tracking entity 
        if (_dbContext.Save() == 0)
        {
            // handle error

        }
        return player;
    }
}
I was reading about anemic data models and rich domain models in DDD. I don't want to follow DDD completely but take rather pragmatic approach and just take some concepts out of it because clean ddd seems like an overkill.
I don't want to maintain separate DTOs just for serializing and deserializing my models.

I'm similarly pragmatic as you, and I agree with you in this situation.
KISS (keep it simple &amp; stupid) applies here. If your application is not sufficiently large, a DTO layer abstraction is not necessary.
I have several colleagues who would disagree with this, this is an open discussion topic. Personally, I disagree with blindly implementing things just because it was needed in other projects. Before I implement something, I need to justify its existence in the current project.

I'm not planning to use any other ORM other than EF Core.

It's not so much about what you plan to use, but rather the chance of this changing in the future, and how prepared you want to be when it turns out you have to change it.


Is it fine if I will design my models like this and at the same time use them as my DTOs for serialization and deserialization?

Yes, as long as you're okay with the tighter coupling and don't start violating SRP by loading everything into your entity classes.
However, that is a separate discussion from whether or not you should use DTOs. You could just as well violate SRP on your DTO class.