Domain-drive-design vs. Comman d pattern — mutually exclusive?

tl;dr:
I like the Command-pattern's small, focussed classes such as SetProjectAsActiveCommand but I also DDD's approach of making models responsible for their own core business functions, such as calling Project::setAsActive(). Can the 2 ideas work together, or are they mutually exclusive architectures?
/ tl;dr
 I've been working on a project for the last few months in which we've been using the Command pattern, which has classes like ProposeNewProjectCommand, SetProjectAsActiveCommand, and AddCommentToProjectCommand, all of which are handled by a command bus. These classes tend to be fairly small and focussed, doing only one thing.
 Recently I've been reading about Domain-Driven-Design (DDD) and I gather that that approach relies more heavily on the Models doing work themselves, so the commands above might be replaced with Organisation::proposeNewProject(), Project::setAsActive(), and Project::addComment().
 Having these methods on Models means they can act as 'aggregate roots' (eg. in the examples above, Project is responsible for creating its own comments).
 Whilst I really like the idea of making my Entities have more responsibility for their core business functions I'm also concerned that my Models could get really, really big with lots of methods on them relating to the various things the application can do.
 Is there a way to have the small, focussed classes of the Command pattern whilst still making Models first-class citizens responsible for their key business functionality like in DDD? Or a way to tackle the potential large-model problem?
 Or, alternatively, should I just pick one pattern and use it exclusively?
 Thanks in advance for any insight you can give,
Harrison
 
 PS. I've never actually worked on an application which uses DDD, so I apologise if this is an incredibly naïve question.