Project background

The target service of this project is identity authentication service, whose basic business process can be abstracted as: checking and verifying the correctness of user identity information through authoritative data sources. Authoritative data sources include bank information, public security database information, industrial and commercial registration information and so on.

Prior to this project, authentication services provided two core business values:

  • As the pre-business of the other two parties to meet the legitimacy requirements of the two parties. That is, the two parties must be real users before performing related operations. Otherwise, they may face legal risks.
  • As a capability to export to third parties through the API;

In the first value scenario, the goal of authentication is to change the status of an internal account to authenticated; The second scenario does not require the concept of internal accounts per se. But the early thinking of product managers was to “support the possibility of customers choosing to use other services”. Therefore, in terms of service form, customers are still required to first create an account through API, and then authenticate the target account. Based on such service positioning, the service model before reconstruction takes account as the center, and the account initiates authentication and maps the authentication result to the account status. The system result of this business model is as follows:

In the implementation of the above model, almost all business requests are forwarded through the user business layer to ensure the real-time and recoverability of user authentication status (that is, after the user authentication process is interrupted, it can be directly resumed from the breakpoint next time).

The problem

As the business progresses, the above model encounters several typical problems:

  1. The application layer and capability layer intersperse user services. The user layer has abstracted and encapsulated the capability layer, so that the upper layer cannot directly and quickly complete the encapsulation of new capabilities.

  2. If the user authenticates through Mode 1 and enters the identity information, When the user switches mode 2 due to abnormal information, the user can not effectively reuse the input information;

  3. Customers want to simplify business interactions and remove complex user creation without using other services.

Existing business models cannot fundamentally solve customer needs, so new models need to be introduced to achieve business reconfiguration. Just use some of its theories to guide the process of building new models.

refactoring

First, Ubiquitous Language was established to expand product richness

At the beginning of the project, several levels of the business should be named and unified strictly as the unified language of the project, and the language should be reflected in the corresponding package, class and field names of the service, so as to achieve Intention Revealing Interfaces and self-explanatory naming.

Information comparison: Sends user information to third-party data for information correctness check. It is synchronous and stateless at one time. VerifyId is used to identify a call.

Kernel authentication: contains two stages of information comparison and user willingness confirmation. It is a process of information verification and willingness verification for a real natural entity, with stages and states.

Real-name authentication: For internal account authentication, the user’s real-name status needs to be refreshed successfully after authentication, including operations on user status.

Two build identityEntity

  1. Domain knowledge

Domain knowledge comes primarily from product managers’ requirements for new product models (simplified):

After collecting/partially collecting user information, the third party customer initiates the identity authentication of the target user through the background.

After opening the authentication link, users can select one or more authentication modes specified by the three parties according to their own conditions. As long as one authentication mode ends, users can be considered to have completed the authentication.

After the user authentication is complete, the user needs to notify the third party and guide the user back to the third party service.

The three parties can actively query user authentication status and authentication information at any time.

Direct objects include third parties, users, and notifications. Indirect objects include authentication processes, authentication processes, and authentication configurations.

  1. Object analysis

  • Third party: in the field of context, information nature does not care about the third party itself, more is to be integrated in the service process, support the integration of business continuity and the data you need dependence, but in order to query in the process of third party certification configuration and the need of secure communication, still need to the third party system identifier appId. Therefore, this object can be abstracted as AppContextInfoEntity temporarily.

  • User: Although the business logic requires the user’s participation, the business process requires the user’s identity information, such as id number and name. You can temporarily abstract this object as ObjectInfoEntity.

  • Notification: what is mapped behind is the processing strategy of the authentication result Event, so an Event object can be abstracted;

  • Authentication process: it represents an authentication initiated by three parties for a specific user. It has the initiated, ended, and ongoing states, and is associated with user information. This object can be identified as the new core object in this project and defined as identityEntity according to the model language.

  • Authentication process: an operation generated after a user selects a certain mode. Due to the complexity of the model, and in the reconstruction of the business model has been relatively clear, not too much explanation;

  • Authentication configuration: policy configuration that is open to a third party to meet its business customization has little relevance to the core content of the model and is ignored in this paper.

  1. Object relational

AppContextEntity: responsible for identifying three parties and their business context information;

ObjectEntity: identity which identifies target users. To be compliant with older models, account ID information can also be used as an attribute of Object.

IdentityEntity: The body of the business logic organization. It has basic properties such as status and is associated with appContext and Object. It can query its properties based on its unique identifier.

StatusChangeEvent: When the status of identityEntity changes, an event is triggered to complete the asynchronous notification of three-party customers, users, and surrounding areas.

VerifyEntity, ProviderEntity and WillEntity are the original services in the system, respectively representing the fields of information comparison and willingness verification. They are mainly written in for subsequent comparison and analysis.

Identify the Entity, Value Object, and Service

According to the definition of Entity in domain-driven design, the most basic responsibility of an Entity is to ensure continuity so that its behavior is clear and predictable. The identity of Entity defines “what conditions qualify as the same thing”.

First, IdentityEntity must be an Entity;

Second, AppContextEntity and ObjectEntity cannot exist independently of the authentication service itself, and identityEntity can still exist without relevant information. At first glance it looks like a Value Object, but there are never two identityEntities that share a context or Object. Because if shared, changes to the data will affect each other. Therefore, they are also defined as entities, but logically their unique identity is attached to identityEntity, and they can use identityId as their unique identity;

Third, at the end of the authentication process, operations such as three-party notification and Service billing need to be completed through the event mechanism, which are activities or actions when identity status changes. Therefore, Envent operation is classified as the type of Service.

The simplified model has no value object. In fact, the configuration information of the three-party platform is a value object information.

Four polymerization

  1. ProviderEntity can be the root within its own aggregation domain to satisfy operations support backend management of suppliers and reference operations of configuration parties using vendor policies;

  2. VerifyEntity is the aggregation root of its own domain in the context of the information alignment business; Third party customers can directly generate Entity through API;

  3. IdentityEntity is the aggregation root of the new model. ContextEntity and objectInfoEntity are intra-domain entities. All external resporitory query and update operations are based on identityId. Also, it is impossible for an external object to refer directly to verifyEntity and WillEntity, so in this scenario, both entities are also in-domain objects.

Design output Resporitory

This section is omitted if sensitive information is involved.

V. Reconstruction Results

Results After transformation:

  1. Three levels of the system can be unified output, output levels are diverse;
  2. After encapsulation, the new abstract authentication domain uses identityId as the core and does not need accountId to simplify customer processes.
  3. Authentication domain and user domain are combined only on the orchestration of the business layer, and no coupling relationship is produced by themselves, which not only realizes the core service reuse, but also completes the domain decoupling.

Write in the last

Standard DDD design involves more means such as requirement analysis, model discussion and recheck after modeling in actual operation. Personally, I think it is the process from requirement analysis to model design of identityEntity in the project that is the key and difficulty. But is limited by its own understanding of DDD degree requirements and the progress of the project, did not spend too much energy on that stage, more on the DDD model representation methodology according to own understanding to the exploration of shallow, a lot of points in the process of design are ambiguous, want to find with the understanding of DDD back to see more improvement points, This is just a summary and record of this stage.