A customizable domain model

Each service layer contains a set of entity classes that reflect the domain model. Domain model objects are used when operating with APIs. APIs accept the objects as part of the input parameters and return objects.

The domain model has been kept to a minimum because all vendors, to some degree, store different information and one model is not for everyone. Nonetheless, the domain models include enough information, domain objects, and parameters to cover common scenarios that are used in all shops.

It is expected that some of the domain model objects are customized for each integration with a different ECS. Commerce Connect might contain domain objects that have no corresponding implementation in the ECS and, in those cases, it is acceptable to leave them as is.

With product synchronization, in addition to the domain model objects, there is also a corresponding item domain model matching the entity classes. The entities can be customized by changing the configuration section.

The domain models are customizable so that:

  • All domain model objects can be inherited and extended with custom properties.

  • All nested objects can be inherited and extended with custom properties.

  • All service methods keep the existing defined signature, even when used with customized domain objects.

We recommend that you create an abstraction layer on top of the ECS that extracts and manages the information to be exchanged with Commerce Connect. This approach is similar to the Bridge design pattern used in computer science and makes it easier to continuously manage the integration as both Commerce Connect and the ECS evolve. It also makes it easier to exchange information if the Commerce Connect domain model and the ECS abstraction layer objects have corresponding and similar object signatures.

Some of the service layers save data in Sitecore, as well as pass the data on to the ECS. Whenever data is persisted in Sitecore, the Repository pattern is used to manage loading and saving data. This makes it easy to replace the actual repository where data is persisted. For information, see the Service layer API  section.