Why not design OroCommerce as a collection of MicroServices ?

OroCommerce team are doing a wonderful job of creating a solid solution for B2B e-commerce. Why not build the whole OroCommerce as a collection of microServices?

This helps in 2 ways

• Helps OroCommerce team to implement things faster
• Helps the Solution Partners to use OroCommerce Services with their custom development & build system for the slightly different purpose

Below are the different MicroServices I have identified based on my working knowledge with OroCommerce

• Product Management Service – Catalogue, Price List, Products Managemnt, Family, Attributes etc
• Order Management Service – Orders, Payment Terms
• RFQ & Quote Management Service – Request for Price, Quote
• Customer Management Service- Customer, Groups, Accounts,Roles, Permissions
• User Management Service – Users,Groups ,Roles, Permissions
• CRM Service – Leads, Opportunities, Accounts, Contacts
• Shopping List Service – Abondan Cart, Shopping Lists
• Organization Service – Organization, Business Unit, Switch Organization
• Auth Service – Authorization & Authentication
• Configuration Service
• Activity Service – Calls, tasks, requests, cases
• Search Service
• Tax Service
• Report Service
• Messaging & Queue Service
• Shipping Service
• Marketing Service – Marketing List, Campaign, Landing Pages, Emails
• Localization Service

Now immediate comment would be installing so many different services. This would be achieved with some installation script in a combination of the composer commands.

On the other hand, development/testing can be done by connecting to the internal stable installation of all services that are maintained for this purpose.

Think of this if I have all these microServices that work independently of each other then I can pick & choose the service to build the different kinds of business systems like

• Invertory Management System
• ERP System
• Saas Subscription System
• Patient Record System
• HR System
• Support Ticket Management System
• Marketing Automation System
• Project Management System
• & more

• This topic was modified 5 years, 9 months ago by  sachingk.30.
• This topic was modified 5 years, 9 months ago by  sachingk.30.
• This topic was modified 5 years, 9 months ago by  sachingk.30.

Topic

[Dima SorokaKeymaster]

Sachin, thanks for the kind words and great question. We are using modular architecture when designing and implementing our applications, such approach allows us to simplify deployment and management of the application, work in parallel on a multiple features and prevent any latency overheads from microservices architecture. Key benefits of microservices architecture (independent stack per service, independent deployment, independent scaling etc.) are great, but less applicable to our reality where we are using same tech stack, deploying and scaling application based on other services built in into it’s architecture (message queue, search index, RDBMS and files storage).

Modular architecture of our applications allows to package and distribute features (services in your list) independent and us such example you can see many packages available available in our GitHub organization: platform, crm, customer-portal, commerce etc. Most of them are not very granular and can be divided into more smaller features which will be used as part of other business applications in different domains. Please let us know if you are interested in splitting some platform/crm/commerce features to dedicated packages, we will be happy to collaborate with you on GitHub.

[sachingk.30Participant]

Hey Dima,

I am definitely interested to split few of the OroCommerce features into dedicated packages. However what I am afraid of is that even if I split them they define the dependency on other packages. Hence the end user will ultimately end up installing all the packages

For example: Let’s say I will split Order Bundle, Payment Terms Bundle, Checkout Bundle into separate packages. But By code Order Bundle has a dependency/refer few functions in Product Bundle which in turn, has dependency/refer few functions to in PriceList Bundle & Tax Bundle.

With that, my goal is not achieved at all. Kindly correct me if I am wrong.

[Dima SorokaKeymaster]

You are correct in case if you consider split as code separation only, but split doesn’t mean code separation only, dependencies should be handled as well.

[sachingk.30Participant]

Right! So even if the code is separated into a package say OrderPackage & it includes OrderBundle, CheckOutBundle, PaymentTermBundle even then this package is not independent. It becomes dependent on ProductBundle.

If the OrderPackage has to be made truly independent then there is a need to bring the change in codes as well.
– Will it not distribute the current stability of the code as well?
– Will it not need force Oro Team to push update into different packages?

I think the true isolation between the modules/bundles can be bought by infusing isolation thinking among the developer. Making adjustment to the current codes that enforce it & ease the development.

As stated, the ROI of such efforts is that one can address business problems of other industry just by including these independent bundles & customizing them as per the need.

[Author]

Replies