Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vertical decomposition of reaction-core #731

Closed
ramusus opened this issue Jan 27, 2016 · 2 comments
Closed

Vertical decomposition of reaction-core #731

ramusus opened this issue Jan 27, 2016 · 2 comments

Comments

@ramusus
Copy link
Contributor

ramusus commented Jan 27, 2016

I want to discuss module structure of the project. There are 2 different ways of organising packages: horizontal and vertical. The difference described here http://meanjs.org/docs/0.3.x/#angularjs-modules.
Looking to the packages like reaction-schemas, reaction-collections, reaction-factories I see horizontal way of modules structure. But to my mind, working with Django Framework and many others since 2009, I dare say, that vertical way is much more practical and comfortable. For example, while implementing package reaction-flat-pages I found that in case of merging this package to the core and following the current paradigm of modules structure, it would be necessary to split this package and put collections to reaction-collections, factories to reaction-factories etc. But I prefer to too keep all parts and functionality of this package in one place and keep this package pluggable and independent from the core.

The same reasons lead meteor team to splitmeteor-platform into smaller packages meteor/meteor#4851

Looking to the structure of reaction-core I always think about decomposition it to the small pluggable packages, for example: reaction-products, reaction-products-variants, reaction-products-tags, reaction-cart, reaction-orders, reaction-packages, reaction-taxes, reaction-i18n, reaction-shops etc. And each package responsible only for little part of functionality and contains all necessary things: schemas, collections, factories, translations, tests and everything to be as much independent from others as it possible. In this case we would have flexible and comfortable configurable constructor for building any e-commerce platform we need. I can easily imaging use case, where we don't need cart and orders, but only products and contact form. Sometimes we need only one shop, sometimes marketplace with multi-tenant functionality (ebay-like). Sometimes we need product with variants, but I believe it should be extra-option with ability easy to switch it on/off, like we discuss here #500.

So, guys, what do you think?

@ramusus
Copy link
Contributor Author

ramusus commented Jan 29, 2016

This issue is related to the question #696

@aaronjudd
Copy link
Contributor

Duplicate of #451

aaronjudd pushed a commit that referenced this issue Feb 3, 2016
- moves product templates from core into
`reactioncommerce:reaction-product-variant`

Related Issues:
- #731
- #451
- #416
aaronjudd pushed a commit that referenced this issue Feb 3, 2016
- moves cart and checkout templates from core into
`reactioncommerce:reaction-checkout`
- adds dependency in reaction-shipping to reaction-checkout

Related Issues:
- #731
- #451
- #416
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants