What is the goal of the service layer in Magento 2?

[joshdifabio]

The first thing I noticed about Magento 2 was the use of dependency injection. The second was probably the service layer, which is potentially just as exciting.

What is the goal of the service layer? Is it intended to provide a manageable and well-defined public API for each module, reducing the remainder of a module's functionality to an implementation detail? If achievable, such an approach would enable us to replace entire modules with different implementations, which would be excellent both in terms of interoperability and in terms of the potential to evolve the platform, but I'm not sure whether this aligns with your intentions for the service layer.

Along these lines, have you considered creating interfaces for the service data classes, e.g. \Magento\Catalog\Service\V1\Data\Product[Interface], and then having your model classes, e.g. \Magento\Catalog\Model\Product, implement those service interfaces in order to eliminate the burden of having to convert model objects to service data objects at runtime?

Currently, Magento 2's inter-module dependencies don't seem to be entirely isolated to the service layer but I'd be interested to know whether this is intended to change.

[antonkril]

New approach to service/data interfaces is described here: https://alankent.wordpress.com/2014/10/31/magento-2-service-contract-patterns/.

Yes, not all modules are refactored for now. It will happen gradually

[choukalos]

@joshdifabio You're correct the goal of service layer is to provide a well defined public API for each module for customization or implementation to reduce upgrade conflicts.

As you pointed out we originally didn't put interfaces on the models but have recently changed based upon feedback received to add those interfaces. As such in the upcoming developer beta release you'll see some differing implementations as we address our revised service pattern. In the end you'll see two ( maybe 3 stages ) of a model refactor: just apis, mutable service*, immutable service. With a mutable service exposing some tech debt that if an extension customizes could cause upgrade issues.

For Dev Beta ( releasing this December ) we'll have the customer module as an example immutable service, Catalog Inventory & Tax as mutable services, base Sales & Catalog as APIs (only REST APIs supported). Our follow on Platform RC release will have all of Sales & Catalog functionality exposed as APIs including integration style Apis ( 1 API call to search + CRUD a business object ), with APIs supporting both REST & SOAP style.

In later 2.x releases we'll continue refactoring modules to add services. We'll communicate those changes ahead of time as a thematic roadmap with the community given the disruption that work could cause on extensions, etc.

If you have any questions or suggestions please ping me.

[joshdifabio]

Anton, thanks for the link. Thanks for the detailed response, Charles, that's all very helpful information. It looks like you guys are doing a great job!