valerylobachev / annette-axon Goto Github PK

Person Service manage list of persons. Person could be one of two types: user or contact. User is the person that have account in system, can connect and perform some actions. Contact is the person who do not have access to system, but needs to be searchable by other users.
Person can be maintained in the PersonService or imported from other sources.
Person have unique person id (that user in others parts of system) and unique user id (only for users).
Person service maintain mapping between person id and user id.
For simplicity Person entity implemented as simple case class having the following attributes:

• id - string - person id
• lastname - string - last name of the person
• firstname - string - first name
• middlename - optional string - middle name
• personType - string? - type of person: user or contact
• source - optional string - source of person data
• userId - optional string - user id of person
• phone - optional string - phone
• email - optional string - email
• updatedAt - timestamp - date/time of last update
• active - boolean - marks person entity as active (not deleted)

Person service provide the following command methods (in CQRS terms):

• createPerson(person: Person): Person - creates person. The following business rules are applied:
  • If person already exists and active it returns exception 400 Person already exist.
  • If person has user id that already exists it return 400 User Id already exist.
  • If personType is contact and has user id, user id is cleared
  • If personType is user and user id is not set, returns 400 User Id is required
• updatePerson(person: Person): Person - update person. The following business rules are applied:
  • If person don't exist, it returns exception 404 Person not found.
  • If person has user id that already exists and not assigned to the same person id, it return 400 User Id already exist.
  • If personType is contact and has user id, user id is cleared
  • If personType is user and user id is not set, returns 400 User Id is required
• deactivatePerson(personId): Done - deactivate person (mark it as deleted), but person's data is still can be requested by person id and remains searchable. User id is removed from UserId index. The following business rules are applied:
  • If person don't exist, it returns exception 404 Person not found.
• activatePerson(personId): Person - activate the person deactivated earlier. If person is a user user id index validated and updated.The following business rules are applied:
  • If person don't exist, it returns exception 404 Person not found.
  • If person has user id that already exists in user id index, it returns 400 User Id already exist.

Person service provide the following query methods (in CQRS terms):

• getPersonById(id: PersonId, readSide: Boolean = true): Person - returns person by person id. By default it return entity from read side that could be updated with some delay. Parameter readSide should be se to false to get more consistent data from persistent entity. If person don't exist, it returns exception 404 Person with user id {userId} not found.
• getPersonByUserId(userId: UserId, readSide: Boolean = true): Person - returns person by user id. f person don't exist, it returns exception 404 Person with user id {userId} not found.
• getPersonsByIds(id: Set[PersonId], readSide: Boolean = true): Set[Person] - returns persons by person ids.
• getPersonsByUserIds(id: Set[UserId], readSide: Boolean = true): Set[Person] - returns persons by user ids.
• findPersons(query: PersonQuery): PersonFindResult - search person using particular query

PersonQuery contains the following attributes:

• offset - Int
• size - Int
• filter - optional String - search by filter in person's names, email and phone
• lastname - optional string - search in last name of the person
• firstname - optional string - search in first name
• middlename - optional string - search in middle name
• personType - optional string? -search in type of person: user or contact
• phone - optional string - search in phone
• email - optional string - search in email
• activeOnly - boolean - search active persons only (by default)
• sortBy - optional string - sort results by field provided

PersonFindResult contains the following attributes:

• total - Int - total items in query
• hits - Seq[PersonHitResult] - results of search

PersonHitResult contains the following attributes:

• id - string - person id
• score - float - store of this hit
• updatedAt - timestamp - date/time of last update

The following test scenarios should be implemented:

1. create person - create one person and validate existing of created person
2. create person with existing person id
3. update person
4. update person with non existing person id
5. deactivate person
6. deactivate person with non existing person id
7. activate person
8. activate person with non existing person id
9. import non existing person
10. import existing person
11. import existing deactivated person
12. get person by id using readside
13. get persons by ids
14. get persons by ids using readside
15. find person by filter, first name last name, email, phone

• #28

Maintain unique index user id -> people id is not required. This constraint could be maintained in external systems (for example: IdP Keycloak)
Removing this constraint can simplify implementation of Person Repository