Yes/No. It depends on how complex your application becomes. As a wise person (I unfortunately do not remember who) once said: “Adding a layer of indirection solves all problems… but one [the problem of having too many layers of indirection]”.

I definitely think that if your application is somewhat larger, that your second approach is better (where ‘better’ means more readable and more maintainable). However, adding an expert layer in-between does mean your code becomes harder to change (which might be a good or a bad thing): Be sure that your modules are set up in such a way, that every module has only a single reason to change (the single responsibility principle).

In this case, the Account.UserImplementation module should only change if the technical details (like the database you use, or what it means, internally, for to be a valid user), whereas the Account.User (the expert layer module) should only change once the expert’s desired functionality changes.

I still think you are somewhat mixing the two responsibilities (keep in mind that a lot of this is personal opinion or ‘gut feeling’, so take this advice at face value, not as ‘absolute truth’):

• generate_uuid() is probably not something an expert understands.
• validate_register() is a weird name. What about validate_when_registering() or User.validate_registration()?
• The expert layer is given the impression that the given pipeline can never fail (e.g. ‘saving will always happen’). Deciding what should happen on failure is often something that should be done on the expert layer rather than in the technical layer.
• data is one of the worst names to give to a parameter, because it is a name that is used for so many different things. What about e.g. form_data?
• Saving is not something the User datatype should worry about. (This is why Ecto made the difference between Schemas and Repos after all).

So what about (it’s a toy example, of course);

defmodule Account do
  alias Account.User

  @spec register_user(%{}) :: {:ok, User.t} | {:error, Ecto.Changeset.t}
  def try_register_user(form_data) do
    |> User.new()
    |> User.fill_registration_details(form_data)
    |> Repo.try_save()
  end

(I won’t write out the internal Account.User module here; suffice it to say that User.new fills in server-generated details such as the UUID).

In this simple example, Phoenix contexts are enough to separate technical details from non-tech code (Phoenix Contexts are, after all, modeled after DDD). If things become more complex, you can always introduce another layer of indirection between the expert layer and the lowest technical implementation level.

I think at the core of this statement was the universal use of “ubiquitous language” for coding artefacts like files, classes, methods, functions, variables, identifiers. If you don’t already have that “glossary of domain terms” set up before you write the code it’s going to be difficult for the domain expert to have something to relate to in your code.

Is Layering Harmful? (1992; pdf)

I’ve never formally done DDD, but I do recall a couple of times, when I contracted at a small insurance company in the Netherlands, I got to pair program with a domain expert (an actuary, so someone reasonably technical I’d say). We were working in Smalltalk and the codebase was quite well written, which in Smalltalk usually means you end up coding in something very close to a DSL. It was a joy, we got **** done in minutes which would have taken weeks through the “official” routes, and I’ve always kept it in my bag of tricks. But I’ve noticed this direct interaction with “users” is rare, for better or for worse, so basically my level of “lift up the language to the domain level, then solve your problem there” (nothing new, a Lisp adage from the '70s I think) is “can I directly read what’s happening and translate that into a user’s language”. To me, keeping related stuff together (a “flow” with all its steps and validations) is more important there than having it written so that I can print it out and hand it off (in Ecto terms, at least keep the whole changeset business and its use pretty close together, or make sure they get called in a very obvious way; i’m fine having bits of Ecto shine through, I’ll make that translation, but I’m not fine having to dig around for snippets of code that make up “user registration”).

(incidentally, that’s why I always loved Seaside, because that framework allows you to do just that, in a very natural way; I have hopes that LiveView might go that way too).