This repository has been archived by the owner on Sep 13, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
Change "Relationship" to "Customer" #42
Comments
I wrote out the documentation for "Customer": """
The `customer` represents the user's role as a customer of the FI. It exists as a separate type
from "User" and accepts an optional `customerId` because some banking systems allow users
to have access to multiple "accounts", which then have "subaccounts". We attempt to reduce
this confusion by referring to each of those "accounts" as separate "customers" and referring
to the "subaccounts" as "accounts".
"""
customer(customerId: ID): Customer Does this capture what we're trying to do? If we applied that same general documentation to "Relationship" would it change our thinking on which name worked best? """
The `relationship` represents the user's relationship(s) to the FI. It exists as a separate type
from "User" and accepts an optional `relationshipId` because some banking systems allow users
to have access to multiple "accounts", which then have "subaccounts". We attempt to reduce
this confusion by referring to each of those "accounts" as separate "relationships" and referring
to the "subaccounts" as "accounts".
"""
relationship(relationshipId: ID): Relationship cc @DeathstarNovember and @treeme |
Here's what other systems call the entity that has accounts:
I'm thinking "customer". |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The idea of "Relationship" seems to be a bit too abstract and leads to confusion as most of the APIs we're integrating use the concept of "Customer" and we find ourselves mapping those two conceptually.
Instead of using:
We'll use:
Note that we're still keeping the distinction between "me" (as the current user) and "customer" (me in my role as a user). This is still an open area for conversation but we'll try this version first.
We still need to handle the idea of "Top Level Accounts" that we've encountered at FIs (particularly credit unions), where they'll have a structure like:
In a previous project we mapped these conceptually to:
While most users only have one account and would thus be well served by a "Customer" that maps to a "Top Level Account", we can handle the multi-top-level-account scenario using an optional
id
parameter passed to thecustomer
query:Notes
The text was updated successfully, but these errors were encountered: