Some user actions quite naturally lead to find-or-create situations. For example, user logs into a system by alternative method and find-or-create is called give email. Or, another example, User is created given Buyer's email. But of course, if there already is a user, that action causes find-or-create. Some databases (think of them as foundations for DDD's repositories) even have upsert functionality for these cases.
On the other hand, I feel that find-or-create is not truly business domain action. Of course, there is a system invariant to be preserved here (for one of the examples above - "each buyer should have a user, identified by email").
There may be also other behavior in between "if does not exist, create; then return existing". For example, logging: are we to log creating separately? Undo: just "find" does not contain anything to undo, unlike "create"; there may be other aspects as well, which come into play in "create" part or only in "find" part, or both.
Given this, how find-or-create should be understood in DDD (domain-driven design)? Is it low-level operation or part of domain logic?
I am aware of debates on how much business logic should live in database for the sake of integrity, this question is not about that. In any practical implementations actions are broken into sub-actions (for instance, as a transaction script). The question is whether find-or-create is usually part of the business or the underlying data access layer? Or maybe this is an example of a very simple service?