Domain Driven Design diagram for Umbrella app

Ask away! Small sidenote though, I’m still building it :wink:

It seems like your app must handle p2p payments and/or payment to use the app. So you handle the payment processing in the core app? Like, use stripe or something within the core app, or did you make a separate app to handle that?

Not really sure about this one yet, I would like to put the general (CRUD) payment logic in the core app but I’m still thinking about this one (and fulfilment as well).

I would imagine webhooks come in via your payment processor from time to time? Do you basically forward those directly to your core app?

I think a small router will handle the forwarding / parsing of the webhooks to the core app.

When a request comes in via your api, where do you put the context plug for graphql? Like, the graphql app needs the context, which is given by the user account’s tokens grabbed from the core app, but is available via the connection in the web app? How did you put that bit together?

The api is an GraphQL, Plug and Cowboy app. Any plug that is needed is placed with the app itself. (same for web) Both use the core app to check the credentials and retrieve the user.

How did you end up handling file uploads with graphql? Are you posting to a separate non-graphql route for uploads or setting it in context?

No sure yet, I’ve tested a couple of setups but haven’t found a good one yet.

Do your graphql resolvers ever call changesets directly or do they only hit up your services?

Only the services

Are your graphql resolvers responsible for checking authorizations, or do your services ask for the authorization first, and the graphql resolver just calls the service?

Guardian is used in both api and web to handle the authentication (token, session, etc). Comeonin is used in the core to handle the user related functions like creating the password hash and checking them.

4 Likes