So the domain-driven-design answer is "go listen to your domain experts", and probe very carefully when they seem to be using the same word for two different ideas with different life cycles.

No domain expert will say "We create a published article from this article"

True, but you may hear them say we published this draft; or we published this submission (not the same thing). Or that a revision was published (also not the same thing).

Article as an aggregate through which the current version and the published version can be accessed. But it seems weird as it basically references it's own versions

Not really that weird -- think source control; we have a document history, and tags that tell us which item in that history is the current development snapshot, and which was used for the nightly build, and which was used for the latest release....

Split the problem into two context (editing and publishing)

Maybe - two contexts (in the sense of bounded contexts from the blue book) usually means different audiences that use the same language with different semantics. If "editors" mean one thing when they say "article", and publishers mean a different thing, then two different contexts can help with that.

But if the editors and the publishers share the same vocabulary, then you might be looking for two different aggregates.

I looked into state pattern but got lost trying to understand how to actually use it in my concrete example.

State pattern works really well for processes; the trick is that the process instance, and the document going through the process, are different things. One keeps track of the work done (state machine) and one is the work (document).

So the domain-driven-design answer is "go listen to your domain experts", and probe very carefully when they seem to be using the same word for two different ideas with different life cycles.

No domain expert will say "We create a published article from this article"

True, but you may hear them say we published this draft; or we published this submission (not the same thing). Or that a revision was published (also not the same thing).

Article as an aggregate through which the current version and the published version can be accessed. But it seems weird as it basically references it's own versions

Not really that weird -- think source control; we have a document history, and tags that tell us which item in that history is the current development snapshot, and which was used for the nightly build, and which was used for the latest release....

Split the problem into two context (editing and publishing)

Maybe - two contexts (in the sense of bounded contexts from the blue book) usually means different audiences that use the same language with different semantics. If "editors" mean one thing when they say "article", and publishers mean a different thing, then two different contexts can help with that.

But if the editors and the publishers share the same vocabulary, then you might be looking for two different aggregates.

I looked into state pattern but got lost trying to understand how to actually use it in my concrete example.

State pattern works really well for processes; the trick is that the process instance, and the document going through the process, are different things. One keeps track of the work done (state machine) and one is the work (document).

Still curious about the state pattern. Can you elaborate on how it can possibly look in my scenario, please?

Processes tend to go well with "event sourcing" -- the current state of a process is just a fold of the events that have happened so far.

DraftCreated
DraftModified
DraftSubmitted
SubmissionRejected
DraftModified
DraftSubmitted
SubmissionApproved
ArticlePublished
ArticleRetracted
...

So imagine a state machine; you start in a Begin state, and each time you see that something has happened, you notify your machine instance of the event, and it calculates the next state.

Metaphorically, we have a piece of paper (the article) inside an envelope (the process). Every time somebody does something to the document, they write what they did on the envelope. You could imagine this envelope moving from one inbox to the next.

The current state is fundamentally the bit that answers questions; given what has happened so far, what things can happen next? who are we waiting on? how long did it take? how much should the author be paid? and so on

A very different set of questions from those you would ask the document: what's your title? how long are you? what reading level are you? and so on.