RFC: Bounded Contexts for CodeCorps API and Phoenix 1.3+

[begedin]

Problem

#749 deals with upgrading to phoenix 1.3

However, part of that upgrade is the encouragement to switch from a flat layer of models/schemas into a concept of bounded contexts

This would facilitate management, maintainability and understanding of the code, but requires some research and discussion before it can be attempted.

I'm already doing some reading, but I would not feel confident in doing this alone, so any ideas are welcome.

Some links to go through:

• https://martinfowler.com/bliki/BoundedContext.html
• https://robots.thoughtbot.com/lessons-from-using-phoenix-1-3

Initial ideas for boundaries

• CodeCorps.Account - creation of accounts, signing in, reseting password, etc, etc

  • probably UserRole, UserSkill, UserCategory, etc, would go here to

• CodeCorps.Forum/ProjectManagement - Projects, Tasks, Comments, Memberships, etc

  • probably ProjectRole, ProjectSkill, ProjectCategory, TaskSkill, would go here

• CodeCorps.Funding/.Stripe/.Payments/.Subscriptions - Stripe/payment stuff

• CodeCorps.GithubIntegration

[hl]

I've struggled with bounded contexts a lot and my problem with it was that the context simply became to big. In smaller projects it would work but for bigger ones like this API I have my doubts.

In the end I decided to place each entity (Product, Shop, Organization, etc) in it's own folder. You can see a small project I've made following the same structure at https://github.com/hl/socka

[joshsmith]

Thanks for the thoughts on this @hl. I think the idea for some contexts here center around the main (fairly different) axes of the product itself: tasks, payments, and GitHub sync. I don't think we'd break it down much further than that anytime in the future.

Would you consider those contexts too large in that case still? Also, what have been the downsides for you of them being too large, i.e. what does that mean for you in practice?

[hl]

Hey @JoshSmith, I'm building an e-commerce PaaS API (with GraphQL) and I've tried to apply the bounded contexts method on Products.

In my case I have Products, ProductPrice, ProductImage, ProductVariant, ProductVariantPrice, ProductVariantImage and the context I created was called Inventory.

Given that each entity has a minimum of 5 functions, create_<entity>, update_<entity>, <entity>_changeset, get_<entity>, all_<entity>, my Inventory context would already have 30 functions. In the end the Inventory context became to large to handle (and had way to many responsibilities).

You can check this gist to give you a peak in the structure I've been working on.

[begedin]

@hl I'm not to invested in defining all "public" functions in the main context module. I know examples and guides point in that direction, but it would make sense to me to define entity functions in their own entity modules.

Main context module functions could be a combination of delegates and, possibly, functions which based on what they do do not belong to a single entity.