Logically, {:error :SUCCESS} seems a bit confusing. If a method returns a result map, one would expect that e.g. if (contains? r :error) resolves to true it would be indicative of an error. Similarly, (:error result) is always true here, even if everything worked out well. This seems a bit counter-intuitive.
Imho, {:error :SUCCESS} is an oxymoron, so I would argue to use something more self-explanatory, e.g. :result :SUCCESS should be used - I would expect :error keyword to be present in a map and to have a non-nil value only in case of an error.
Logically, {:error :SUCCESS} seems a bit confusing. If a method returns a result map, one would expect that e.g. if (contains? r :error) resolves to true it would be indicative of an error. Similarly, (:error result) is always true here, even if everything worked out well. This seems a bit counter-intuitive. Imho, {:error :SUCCESS} is an oxymoron, so I would argue to use something more self-explanatory, e.g. :result :SUCCESS should be used - I would expect :error keyword to be present in a map and to have a non-nil value only in case of an error.