I understand your reasoning. In general, I prefer flat maps over nested maps. One point I’d disagree with you is that I care about code organization if it helps reduce the cognitive cost of working with code. For example, I prefer to organize my codebase in such a way that symbols and namespaces match up nicely:
(defn phone-number [entity]
(let [contact (::entity/contact entity)
phone-number (::contact/phone-number contact)]
phone-number))
That said, I also understand your point. Creating separate namespaces/entities leads to more design considerations.
To analyze it from a DDD point of view, it’s ultimatley a matter of whether a concept in question is a first-class domain entity. Without doubt, “account” is a first-class entity. “Profile,” “contact,” or “preferences” may or may not be. If one wants a rich functionality on a concept and if the concept appears in multiple entities, one could justify giving the concept a first-class treatment by offering a proper namespace and upgrading it to entity.
From a stylistic and organizational perspective I discussed above, I have so far avoided having keywords with different namespaces in the same map so that an account entity can contain ::account/some-key but not ::profile/some-key. I am curious which side clojurians tend to take on.