WIP + RFC - chore(docs): Add node style guide supplemental #517
Conversation
Because: * Add supplemental section to node style guide to provide additional information This commit: * Adds supplemental section with Software Architecture Implementation doc
StaberindeZA
force-pushed
the
software-arch-sup
branch
from
e74ed3a to
bd1a82b
Compare
StaberindeZA
changed the title
| 'reference/style-guides/supplemental/software-architecture-implementation', | ||
| ], | ||
| }, | ||
| 'reference/style-guides/react-style-guide', | ||
| ] | ||
| }, | ||
| { |
There was a problem hiding this comment.
Is there any way to include the graph in whatever raw format/non-image as well so it's more easily editable later if needed? Not sure what tools we are all using for charts.
| @@ -0,0 +1,155 @@ | |||
| --- | |||
| title: Software Architecture Implementation | |||
There was a problem hiding this comment.
Edit: probably never mind. I was looking at this from the direct link and totally thought I was in adrs/ in fxa.
Should this be more specific? If I'm looking at the title list in adrs/ and I see this, I'd have to click into it to understand what this was covering specifically.
| * Client => StripeClient ([code](https://github.com/mozilla/fxa/blob/main/libs/payments/stripe/src/lib/stripe.client.ts)) | ||
| * Manager => StripeManager ([code](https://github.com/mozilla/fxa/blob/main/libs/payments/stripe/src/lib/stripe.manager.ts)) | ||
| * Service => StripeService ([code](https://github.com/mozilla/fxa/blob/main/libs/payments/stripe/src/lib/stripe.service.ts)) |
There was a problem hiding this comment.
This is probably a bad example, because this demonstrates organization by the specific 3rd party implementation rather than organizing by feature. In organizing by feature (as shown the repository example blow), one would instead off a StripeClient, an InvoiceManager/SubscriptionManager/CustomerManager/etc, and then an appropriate service above based on the feature in use.
The problem with this example is that the StripeManager ends up duplicating the StripeClient for the most part, rather than implementing invoice or customer specific logic that may involve multiple clients (e.g. asking the InvoiceManager to pay an invoice would involve the PayPalClient and StripeClient, and even several repository methods). It also means that StripeManager becomes a massive class like our current StripeHelper, rather than organizing by feature which keeps them smaller.
Because
This pull request