Party Service

Overview

In order to design a CRM system, it is necessary to manage the party information and identify party types. Adam and Alexander discussed how to manage the different parties in the CRM system. They have identified the need to have a party service as a standardized schema for a person or an organization. The employee and customer services then will integrate the party service as each has different specific data.

Introduction

This document describes the Party service and the required attributes for party related information. As you read through these documents, you can identify the different levels at which the service is designed.

What is the scope of the Party service

This service maintains a comprehensive set of party information and handles the basic details of a party. Depending on the type, different information is managed in the service.

Here is an overview of entities that have been created for the Party service:

By taking the reference from the above UML, Jack and Alexander have designed and built the service in the tool. As mentioned in the previous services, the tool provides the three layers API, domain and integration namespace that make the service functional. The Party Service has been designed with multiple namespaces which covers different information around the party.

Designing of Party Service

The design of the service has been classified into the following namespaces:

Domain Namespace

The Party service has two concrete entities, organization and person. The main structure of the party service is inspired by the ISO. The main three properties are the Identification, status and contact points. The identification property indicates the name of the party while the status indicates either the party is active or not. The contact points property indicates different contacts such as address, phone number, postal address, email address. Each party can have one or more contact points.

Entities

The Party service has different entities but the most important one is the Party entity. It is a root entity designed to be abstract. The organization and person entities are the main entities in the Party service as they are considered different types of a party. The following are the properties in the organization entity.

As you can see, the commands designed with the organization entity are as follows.

As Adam discussed with the team, they have decided to design the property taxIdentifikationNumber in class PartyIdentificationInformation as a unique value. Based on this, a business error NoDuplicatesAllowed was designed to prevent adding parties with a duplicate tax identification number.

For the Person entity, it is very similar to the organization entity bus with slight different properties to identify the person specific data.

As you can see, the commands designed with the organization entity are as follows

Similarly, the property taxIdentifikationNumber in class PartyIdentificationInformation as a unique value. Based on this, a business error NoDuplicatesAllowed was designed to prevent adding parties with a duplicate tax identification number.

Events

As you can see below, there are four events in the Party Service; PartyCreated, PartyNameChanged, PartyStatusChanged and PartyUpdated.

Errors

Alexander modelled all the errors based on the logic of the previous entities and events. The following are the errors designed in the Party Service.

API Namespace

After designing the domain namespace, Alexander covered all the important points around the API namespace. This section guides you through the different parts of an API.

Paths

Alexander designed several paths which can be performed as part of the API in the Party Service. Paths are typically provided as endpoints for APIs. For each path, multiple operations can be created to perform the desired action based on the HTTP verb.

Schemas

Alexander has also designed schemas within an API namespace. A schema represents a data type of an API. The API namespace of the Party service contains Object schemas as well as Array schemas. The party schema is designed as a oneof schema, it can either be person or organisation. A child schema with one value is designed for the person and the organization. The discriminator property then holds the child schema value to be able to differentiate between the two schemas.

💡tip

The discriminator value should be the name of the schema itself.

Parameters

The only paramter in the Party Service is the partyId which is used in different operations.

Request Bodies

There are no designed request bodies for the Party Service.

Responses

Adam and Alexander defined some error responses. Each error response can be used in several occasions.

Integration Namespace

Integration namespaces are used to consume other REST APIs. For the Party service, no external API has been integrated.

🌟Congratulations!

You have covered important artefacts about the Party Directory service.