Customer Service: Customer Domain

[usharik]

Prerequisites Customer Service stores data representing a customer that inquired a product at least once. This data specifies details about a customer, mostly for establishing a communication with. This data is not static, however changes quite rarely. This data can't be changed by customer rather requesting any change to a manager. Usually this data is needed while a manager does operations (changing status, making any decision, arranging purchase, etc.) with an inquiry.

What will happen if a customer bought any product? It should be propagated to a system called User Profile. That system is abstract storage for all user even created in a system (e.g. customer that bought a product, manager that works with the system, system administrator, etc)

Structures:

• Customer

  • id (PK)
  • name (varchar, max. length 30 chars, not-null)
  • surname (varchar, max. length 30 chars, not-null)
  • country_code_id (FK, not-null)
  • contact_details_id (FK, not-null)
  • createdAt (timestamp with timezone, UTC+0 only, not-null)
  • updatedAt (timestamp with timezone, UTC+0 only, not-null)

  Relations Country: Many-2-One ContactDetails: One-2-One

• Country

  • id (PK)
  • country_code (varchar, min.max. length 3 chars, not-null) // ISO 3166-1 alpha-3
  • name (varchar, max. length 30 chars, not-null)
  • createdAt (timestamp with timezone, UTC+0 only, not-null)
  • updatedAt (timestamp with timezone, UTC+0 only, not-null)

  Any purchase may be made in any possible country with different language support. Hence, internationalization (i18n) is crucial part of every single product. Because of that name attributes represent a key based on what a corresponding translation will be applied.

• ContactDetails

  • id (PK)
  • email (varchar, max. length 50 chars, email-pattern, not-null)
  • telegram_id // e.g. @testuser
  • createdAt (timestamp with timezone, UTC+0 only, not-null)
  • updatedAt (timestamp with timezone, UTC+0 only, not-null)

Telegram ID must match Telegram format.

Once persistent layer implemented, a service layer for introducing required business operations must be implemented. Operations:

• Create Customer
• Update Customer:
  • Lightweight ops:
  • Name
  • Surname
  • email
  • Telegram ID
  • Country
• Find customer by ID
• Find all customers
  • Pagination (default limit 25)
  • Filtering:
  • full name
  • country
  • Sorting:
  • country

In order to implement service layer tests we have to have a storage to prove that data fetch, add, update, etc. For this we will integration tests approach in combination Spring Boot Test + Testcontainer. Testcontainer will help us to establish a storage and populate data in it.

NOTE: Do not need to cover Spring Repositories with tests

So that,

• Tool for DB versioning configured
• Domain implemented on persistent and service layers
• Test data prepared for being populated
• Testcontainer established
• Solution covered with integration tests

DoR

• Persistent layer is ready to use
• Service layer is ready to use

[A-Sakhmina]

Steps:

1. application.properties 1.2. add database connection 1.3. liquibase connection
2. add mvn dependency in pom.xml
3. create classes with Entity
4. Liquibase 4.1. changelog file master.xml(or yml) 4.2. add changelog files for create

Links

1. Use Liquibase to Safely Evolve Your Database Schema
2. Liquibase + Spring Boot ➡ Настройка и написание миграций