Module separation #145
Module separation #145
Conversation
|
|
melnikovi
added
the
services isolation
|
I guess rewriting all old modules in a new manner its a too big change in terms of backward incompatibility. Developers should not just align their modules, they have mostly rewrite all of them. |
design-documents/module-split.md
Outdated
|
|
||
| Common code (business logic used by multiple areas, models, resource modelss) | ||
| * CatalogCommon | ||
| * CatalogShared |
There was a problem hiding this comment.
Not sure about Common and Shared, it assumes that the code under these namespaces knows about its usage in the different areas. I propose to combine these namespaces into something like Domain.
design-documents/module-split.md
Outdated
| Cons | ||
| * Backwards incompatible, all of the extensions will be affected | ||
|
|
||
| 3. Keep old namespaces. Classes in CatalogAdminUi, CatalogStorefrontUi, CatalogCron, etc will have Catalog namespace |
There was a problem hiding this comment.
New classes probably will have new namespaces as we don't need to preserve backward compatibility for a new code.
There was a problem hiding this comment.
Yes. Added this for clarity.
design-documents/module-split.md
Outdated
| * No overhead from preserving keeping backwards compatibility | ||
|
|
||
| Cons | ||
| * We going to have incorrect namespaces |
There was a problem hiding this comment.
The namespaces are not incorrect. They simply don't follow the same pattern. The composer autoloader thinks they are perfectly valid.
There was a problem hiding this comment.
You are right, I will rephrase.
design-documents/module-split.md
Outdated
| * No overhead from preserving keeping backwards compatibility | ||
|
|
||
| Cons | ||
| * Backwards incompatible, all of the extensions will be affected |
There was a problem hiding this comment.
This should not even be an option. You're talking about completely breaking every extension in the ecosystem overnight; causing every single extn developer to go fork their extn into two versions, one for older magento and one for this; and causing every develop to have to learn a new paradigm. You know the costs of all that across the ecosystem is easily hundreds of thousands of dollars and right?
design-documents/module-split.md
Outdated
| * CatalogCron _recommended_ | ||
|
|
||
| CLI (models and resources potentially) | ||
| * CatalogCli _recommended_ |
There was a problem hiding this comment.
Need to clarify how the CLI will be used.
design-documents/module-split.md
Outdated
| * CatalogCli _recommended_ | ||
|
|
||
| WebApi (models and resources potentially) | ||
| * CatalogWebApi _recommended_ |
There was a problem hiding this comment.
Should we split on SOAP, REST and GraphQL?
There was a problem hiding this comment.
REST and SOAP have unified implementation, but represent different areas.
GraphQL is completely separate implementation and area.
There was a problem hiding this comment.
We can't support some things for REST and SOAP at the same time, like associative arrays (SOAP doesn't allow to use them). Probably it makes sense to separate REST and SOAP.
design-documents/module-split.md
Outdated
| * CatalogWebApi _recommended_ | ||
|
|
||
| Common code (business logic used by multiple areas, models, resource modelss) | ||
| * CatalogCommon |
There was a problem hiding this comment.
Please consider having this module named Catalog and have metapackage named CatalogMetapackage (or something similar).
The issue is that third-party modules will not be able to get seamless upgrade if they depend on current Catalog. We need to evaluate how realistic is that we will not bump major version of the Catalog package with this module split.
There was a problem hiding this comment.
The idea was to don't introduce a new name and 3rd party developers will have a possibility to specify multiple versions in composer (option 3 from https://github.com/magento/architecture/blob/master/design-documents/service-isolation/split-extensions.md#new-module---old-composer)
design-documents/module-split.md
Outdated
| The following is proposed naming for modules: | ||
| Admin Ui and admin related business logic (blocks, controllers, static resources, models and resources potentially) | ||
| * CatalogAdmin | ||
| * CatalogAdminUi _recommended_ |
There was a problem hiding this comment.
Should we drop Ui postfix? We can have a case when resource model is only relevant only in storefront, as it's not UI it can be confusing.
There was a problem hiding this comment.
Decided to leave Ui postfix.
Problem
Proposal describes different options for module names and namespaces when splitting modules.
Solution
Requested Reviewers