Domain-drive-design vs. Command pattern — mutually exclusive? -

tl;dr:
command-pattern's small, focussed classes such setprojectasactivecommand ddd's approach of making models responsible own core business functions, such calling project::setasactive(). can 2 ideas work together, or mutually exclusive architectures?
/ tl;dr

i've been working on project last few months in we've been using command pattern, has classes proposenewprojectcommand, setprojectasactivecommand, , addcommenttoprojectcommand, of handled command bus. these classes tend small , focussed, doing 1 thing.

recently i've been reading domain-driven-design (ddd) , gather that approach relies more heavily on models doing work themselves, commands above might replaced organisation::proposenewproject(), project::setasactive(), , project::addcomment().

having these methods on models means can act 'aggregate roots' (eg. in examples above, project responsible creating own comments).

whilst idea of making entities have more responsibility core business functions i'm concerned models really, big lots of methods on them relating various things application can do.

is there way have small, focussed classes of command pattern whilst still making models first-class citizens responsible key business functionality in ddd? or way tackle potential large-model problem?

or, alternatively, should pick 1 pattern , use exclusively?

thanks in advance insight can give,
harrison

ps. i've never worked on application uses ddd, apologise if incredibly naïve question.

what makes ddd, start thinking language more, you're trying model in code "syncs" understanding of domain. actual implementation patterns are, well, implementation details. example, can try if there's better ways of expressing commands, eg setprojectasactivecommand -> activateproject; addcommenttoprojectcommand -> commentonproject. rid of developer language (set, add, command) in favour of domain language.

commands, in approach, don't (they're not gof commands). messages, representing user's intention. aggregates (and entities, value objects, ...) represent our structural domain model. know how things, make decisions, protect business rules, ... in between messages , decision making, there needs receives message , translates domain model. command handlers: they're dumb, make sure message reaches right aggregate. often, command handler little more fetching aggregate repository , tell something, without understanding internals. neatly decouples commands domain model.

you can tell i'm big fan of style of code organisation. think it's useful ddd. can apply ddd in many other ways. in end, goal not "do ddd", build systems solve problems, testable , maintainable , evolvable.