Delivery service API for processing orders for Personal or Enterprise deliveries
Design and implement a domain service that will process these three delivery orders (JSON file can be found here) and return appropriate types of objects based on the delivery type with the following specifications:
- Each delivery type can have a different workflow.
- Delivery with “enterpriseDelivery” type needs to be sent off to a 3rd party API for validation of the enterprise.
- Delivery order coming from an email campaign needs to communicate with a separate marketing service indicating the success of the given email campaign.
Notes:
Demonstrate the use of SOLID principles, design patterns and domain driven design. Indicate and showcase what sort of automated testing procedure would you recommend to use for such a service.
- The code does not have to be 100% functional, the purpose of this test is to get insight into your problem solving process and your understanding of the OOP.
- We are looking for encapsulation, inheritance/abstraction and polymorphism.
- Provide readme.md to explain your thought process.
- Please deliver the code via a public version control repository.
Looking at all the delivery_types provided in the JSON payload two main types were identified which was either the delivery is going to be personal or an enterprise.
Since enterprise delivery order is going to be using the same fields as the personal delivery order it made sense to use Inheritance to create a base class "DeliveryOrder" for doing personal delivery orders (doesn't matter if the order is express delivery or not). Another class was created "EnterpriseDeliveryOrder" which extends from "DeliveryOrder". Having this setup made sharing of code quite simple and I could further extend the structure for new delivery types (if required).
Some delivery orders could have originated from an email campaign so the requirement was to notify the marketing department after processing the order. Having a link for ANY delivery order to be linked to a campaign (even enterprise deliveries) was something that was assumed.
Once delivery orders are recorded within the system we then go about processing them and we tackled this problem by introducing a Provider concept located in "src/Provider" dir.
"DeliveryBase" is the base abstract class it has some shared logic/functionality that is common across a Personal or Enterprise delivery processing. For instance since I have assumed that Email Campaign can be linked to any delivery type we can process the marketing notification workflow as a postProcess task.
"PersonalDelivery" or "EnterpriseDelivery" both extends from abstract DeliveryBase but they both can have their own workflow. For instance EnterpriseDelivery had a preProcess task of validating the enterprise info from the payload.
Automation testing was implemented using Codeception unit tests (located in tests/unit dir). A few unit tests were created to demonstrate the possible scenarios that could break the processing workflow.
Test #1: Process dummy orders payload with no customer info
- ensures we do not process any orders that have no customer info
Test #2: Process dummy orders payload with no enterprise info
- ensures we do not process any orders that we have no enterprise info (as we require this info for validation)
Test #3: Process dummy orders payload
- test designed to make sure we can process orders that actually have all the required info
To run the project
- Composer must be installed and have to have php 7.2 and above
- "composer install" to update vendor dir with necessary libraries (vendor dir may need to be created first in the root dir)
- "php bin/console server:run" to get the site up and running locally
- Then navigate to "http://127.0.0.1:8000/api/test" to observe the code working as per the business rules stated above in the "Problem".
- You can also do "vendor/bin/codecept run unit" to run all unit tests.
The Delivery Service API doesn't rely on a database for the time being.