The complexity of the business logic, alternatively called the application behavior, is the most important factor. The second most important factor is how much of a gap there is between the technical problem and the business vocabulary used to describe that problem, since DDD is about creating a shared vocabulary between the business and the engineering team.
Some of the patterns used in DDD are generally useful in enterprise application architecture, such as the Repository pattern, Bounded Context, and Layered Architecture. Just because you're using those patterns, doesn't mean you're doing domain driven design.
If there's not much behavior, which is to say, you're mostly storing data, and not acting on that data, there may be much less value in building out that domain layer. In content management, if all you do is approve and publish, maybe that can be represented by flags in the system, rather than domain methods. But when you start adding additional behavior, the appropriateness of a full-on domain layer becomes more apparent.
If we're talking about content management, here are some (imagined) rules that might start to hint at the need for DDD:
- If story is embargoed until date xx/yy/zz, publish to print, then to web; if there's no embargo, publish to web and make available for print
- Make this story available behind the paywall to paid subscribers immediately; release to the general public 2 weeks later.
- After a story is written, send it to an editor for revision, proofreading, and approval. When approved, send it to production. If production cuts up the story for space reasons, make an extended version available online.