Challenge Overview
1 Project Overview
The aim of this project is to build a customer database system (similar to a CRM system) to enhance the customer experience, marketing effectiveness and regulatory reporting of our client’s website. The customer database system will capture customer data from multiple channels and provide a single customer view/access point to various applications across the corporate domain.
The project will be implemented in several phases, and while this architecture challenge will only focus on the business requirements for phase 1 (basically functionality related to online customers and basic customer information), it must also be designed in such a way that it is flexible/extensible enough to accommodate requirements for later phases with minimal efforts and no significant architectural changes.
2 High Level System Design
The following diagram illustrates the high-level system design.
REST APIs
Directly exposed to various channels (i.e. API clients) is the REST APIs layer, it will be exposed via HTTPS and use JSON as the payload. This layer will be implemented using Spring MVC technology and will be kept as thin as possible by delegating major business logic/rules to the layer underneath it.
Business Logic/Rules
This layer will include custom Business Services implemented as POJOs (Plain Old Java Objects), BRMS (Business Rule Management System) using JBoss Drools.
The custom Business Services will implement core business logic such as customer registration, order tracking, etc., and they should abstract out configurable business rules and delegate to BRMS (Drools) for rule execution. It will access database persistence via Domain Models.
The BRMS will be responsible for declaring and executing configurable business rules, e.g. password policy, required customer identification information per country/channel, database archiving policy, security policy, etc.
Domain Models/Persistence
This layer will provide raw access to database persistence, largely via Domain Models implemented using JPA technology.
A few major domain models are identified and presented below for your reference, please refer to detailed requirements document and extend the models accordingly.
3 Requirements
Detailed requirements are available in “Database Specification.docx”, this section summarizes the APIs to expose and integrations to implement, please treat this section as high-level suggestions and for reference only, please refer to detailed requirement document and propose full set of APIs addressing the requirements.
3.1 Exposed REST APIs
In phase 1, the following high priority REST APIs must be exposed from the customer database system:
· Customer Registration
· Customer Change Password
· Customer Authentication
· Customer Profile Retrieval/Search
· Deactivate Customer Account
· Transfer Customer Data in Batch
· List/Search Order History
· Get Order Details
· Manage Customer Profile Options
3.1.1 Customer Registration
This API will be used to register a customer account.
Note that this API needs to verify customer data submitted from the API caller, to ensure the data conforms to required business rules, some example rules might be
· Email will be required (F01.1)
· Date of birth will be required if the source channel is SALT in UK (F01.5)
· Delivery address must match the country (F01.3)
· Password must match specified policy
Input:
· Customer account information (email, name, addresses, etc.)
· Registration method information
o Source channel (SALT/Mobile/etc.)
o Country
Output:
· Customer registration confirmation (Customer ID, etc.)
· Confirmation email sent to customer
o Includes password reset instructions if registration was done offline or opt for one click registration online
3.1.2 Customer Change Password
This API will be used to change a customer’s password.
Note that this API needs to verify if the new password meets the defined password policy.
Input:
· Old password
· New password
Output:
· Password change confirmation
· Confirmation email sent to customer
3.1.3 Customer Authentication
This API will be used to authenticate customer user.
Input:
· Username/email/password
Output:
· Access token that will be used in subsequent API calls
3.1.4 Customer Profile Retrieval/Search
This API will be used to retrieve or search for customer profile(s).
Input:
· Customer ID/email/username/other search criteria
Output:
· Customer profile
3.1.5 Deactivate Customer
This API will be used to deactivate a customer.
Input:
· Customer ID/email/username
Output:
· Customer deactivation confirmation
3.1.6 Transfer Customer Data in Batch
This API will be used to transfer customer data in batch format.
Note that this API needs to verify customer data submitted from the API caller, to ensure the data conforms to required business rules, some example rules might be
· Email will be required (F01.1)
· Date of birth will be required if the source channel is SALT in UK (F01.5)
· Delivery address must match the country (F01.3)
· Password must match specified policy
Input:
· Customer account information (email, name, addresses, etc.)
Output:
· Confirmation (Customer IDs, etc.)
3.1.7 List/Search Order History
This API will be used to list or search the order history for a customer.
Input:
· Search criteria
Output:
· Order history
3.1.8 Get Order Details
This API will be used to get order details.
Input:
· Order ID
Output:
· Order detail
3.1.9 Manage Customer Profile Options
This API will be used to manager customer profile options:
· Payment options (note that we will store the last 4 digits of a credit card and an expiration date here, with a token that references an external system for the full payment details. The API will NEVER deal with the full credit card number).
· Marketing options
· Addresses
· Customer consents/agreements
Input:
· Customer profile options
Output:
· Confirmation
3.2 Integration with online channels (SALT/Mobile)
In phase 1, the integrations with online channels (SALT/Mobile) will be implemented, the following integration requirements shall be covered in this architecture. Please clearly document how the integrations will be implemented. (see document in forums)
· F01.6 · F01.7 · F01.8 · F01.14 · F01.16 · F01.19
· F02.1 · F02.2 · F02.3 · F02.4 · F02.5 · F02.6 · F02.7 · F02.8
· F03.2 · F03.3
· F06.05
· F07.01
3.3 Security
The REST APIs must be accessed via HTTPS to ensure secure communication.
Access to all REST APIs must be secured using access tokens. Two types of access tokens will be supported:
· Long-term Access Token used in general integrations with corporate systems (SALT/Mobile/RTS/etc.) that are not specific to a particular customer (i.e. not acting on behalf of a particular user). This type of tokens will be pre-generated and configured at API callers.
· Short-term Access Token used to act on behalf of a particular user (e.g. a customer). This type of tokens will be obtained via Authenticate REST API call and will be used in subsequent API calls.
It is suggested to pass the access tokens as part of HTTP Authorization header. Please have a look at OAuth signing and validation for the long-term access token and standard bearer token authorization headers for the short-term access token. We don't want to reinvent the wheel here - if a standard approach fits and meets the requirements, that would be best as opposed to implementing a custom solution.
3.4 Auditing
Audit trails should be available for all transactions including content changes. It is suggested that this is accomplished in two steps:
· Use database triggers to automatically keep track of database history in separate historical tables.
· Use an AuditRecord Domain Model to keep track of each action performed in the system
Detailed Requirements
- The specification document posted in the forum contains further details and information you may use for this challenge.
Technology Overview
· Java 7
· Spring Framework 4.x
· Spring MVC
· JPA 2.1
· SQL Server/PostgreSQL/To Be Defined
· JBoss Drools
· JBoss AS
· REST APIs
Final Submission Guidelines
Documentation Required
· Application Design Specification
· Database Schema / ERD
· REST API Specification (swagger.io format)
· Brief assembly Specifications with a suggested gameplan to implement this phase
UML Diagrams
o Class Diagrams
o Sequence Diagrams