Doubt about the organization of the directory structure of a project phoenix with ecto:

Phoenix Forum Questions / Help
, ,
1

Guys, I would like to take a doubt about the organization of the directory structure of a project phoenix with ecto:
Considering the example below:

Entities: account, login and transaction
Aggregates: account and login
Contexts: account, login and transaction

Can you consider that the organization below would be ideal? If not, what should change?
What is generally recommended to model my domains, entities/aggregates and contexts in a phoenix system?

system-service
Accounts - Directory for account context
account.ex - implement my account entity schema and changeset
login.ex - implement my login entity schema and changeset

	accounts.ex - implement my persistence layer using ecto, within the account context. As the login is an account aggregate, here would also be the persistence layer of my login
		Example of methods that would be inside here:
			def insert_account(attrs) do
				Account%{}
				|> Account.changeset(attrs)
				|> Repo.insert()
			end

			def insert_login(attrs) do
				Login%{}
				|> Login.changeset(attrs)
				|> Repo.insert()
			end

			def prepare_account(params) do
			    %{
			      key: params["key"],
			      key_type: params["key_type"]
			    }
			    |> Map.put(:document, params.document)
			    |> Map.put(:type, params.document_type)
			    |> Map.put(:email, param.email)
			    |> Map.put(:name, param.name)
			    |> Map.put(:telephone, param.telephone)
			end

Transactions - Directory for transaction context
	transaction.ex - implement my transaction entity schema and changeset

	transactions.ex - implement my persistence layer using ecto, within the transaction context
		The methods here is similar from above method, but for my context transaction

accounts.ex - implements my business rules from the context of accounts, for example the flow of creating an account.
	Example of method that would be inside here:
		def create_entry(params) do
		    params
		    |> verify_valid_document()
		    |> verify_valid_email()
		    |> verify_if_document_already_has_account()
		    |> Accounts.prepare_account(params)
		    |> Accounts.insert_account()
		    |> handle_create_entry()
		end

transactions.ex - implements my transaction context business rules, for example the flow of creating a transaction.
	The methods here is similar from above method, but for my context transaction

logins.ex - implements my transaction context business rules, for example the flow of a user logging into the system.
	The methods here is similar from above method, but for my context login

system-service-web

router.ex - router of file

controllers
	account_controller.ex - will call my context that has my business rule linked to this controller(in this case accounts.ex)
		Example of method that would be inside here:

		def create(conn, params) do
		    with {:ok, result} <- Accounts.create(params) do
		      conn
		      |> put_status(:created)
		      |> render("show.json", account: result)
		    end
		end

	transaction_controller.ex - will call my context that has my business rule linked to this controller( in this case transactions.ex)
		def create(conn, params) do
		    with {:ok, result} <- Transactions.create(params) do
		      conn
		      |> put_status(:created)
		      |> render("show.json", account: result)
		    end
		end

Plugs - directory for plugs if necessary

providers - external providers my application needs to communicate with
external_api - external api to get some data
context.ex - this context will be called from some context that is in the root of the system-service directory and this context will call the client.ex
client.ex - client that will implement communication with an external api

1 Like