DDD Elixir/Phoenix registration form with many bounded context fields

Mayby its not a Elixir/Phoenix problem, but i have it in Elixir project, so i think this is right place for this question.

So. I have a project build from 3 services. All build on Elixir/Phoenix
Frontend → just for test. In the future will be rewritten to React probably
Auth → module for authenticate. based on guardian
Core → whole system. Including REST API and Console Admin.

And now i have few question.
First one is how to deal with multi services data. I mean for example register form. One of required field is for example your favourite food. Another is your weight. That fields doesn’t fit to Auth module.

So i decided to build system like this
Front (html) send request to Front Controller
Front Controller send request via Tesla to Core Service
Core Service prevalidate fields and then send request to Auth Service
Auth Service validate own fields (like password), and if everything is OK, save new user and send back info do Core Service.
Corve Service save other fields including uuid given from the Auth system

Is this correct way to to this?

Front --> Core(pre validation) --> Auth(validation and save) --> back to Care(save) --> back to Front with succes message.

There is few issue. First one, how to deal with validation of another system. For example password field. Core doesnt have to know anything about password. But if i don’t validate this field user won’t know that password is invalid unitl i ask Auth for it.

Another solution is send request from front to both services. But what if one of them have invalid data? It should like below?

# register_controller.ex
  def register(conn, params) do
    with  {:ok, validated_client_params} <- API.Core.validate(params),
            {:ok, validated_user_params} <- API.Auth.Core.validate(params),
            {:ok, client} <- API.Core.create_client(validated_client_params),
            {:ok, user} <- API.Auth.create_client(validated_user_params) do
            render("submit.html", client: client, user: user)
    end
  end

But there is 4 request to do simple thing like create new user. SLA of this solution is terrible.

Second question is related of this topic.
What if i have many fields on form but they are from different bounded_context in my backend?
Like i said before i have AUTH like another service (security policy)
In Core i have few bounded context.

• Client for basic information about client
• Limits for restrict acces to resources
• Foods for food catalog
• Diet for create new diet plan based on foods and related to clients or dietician.

So how should i implement it if on register form i have to put field from diet context, like → prefered diet, or mentioned favourite food, to better target diet advertisement?

I’m thinking about register scope/controller/view. This is only virtual scope. By virtual i mean only in web parts. This concept won’t appear in my contexts.

It could looks like this

# web/api/register.ex
  def register_controller(conn, params) do
     with {:ok, client} <- Clients.create(params),
             {:ok, food_preferences} <- Foods.create_if_not_exist(params),
             {:ok, diet_mentor} <- Diet.related_dietician_mentor(params),
             {:ok, diet_preferences} <- Diet.create_diet_preferences(params) do
                conn |> ...
   end
 end

# clients.ex
def create(params), do: Client.changeset(params) |> Repo.insert()

# foods.ex
def create_if_not_exist(params), do: ...

If anyone need to change the same field in the future i have to add another controller but now in separated bounded_context. registration context is just for keep whole process consist and isolatet from external word. I mean Front apps shouldn’t know which fields are related to which bounded context. Core could save all of this fields to keep “copy” but source of true is bounded context which update state.

Thanks for any advice!
Mayby there is easier way to do that?

Any good books/wideos to read/watch. On Elixir ofc.

I watched this wideo twice: https://youtu.be/l3VgbSgo71E
I think its pretty good, but still i don’t know how to deal with this concept in practice