Domain Driven Design (DDD) with stakeholders: using content production contracting as an example

In my previous article, I focused on the development part of DDD, but this time I would like to delve into the preliminary part. So, using the business challenges of a fictitious company as an example, we will consider how to understand the business process and how to leverage the knowledge of experts to build a system.

Step 0: How the Project Begins

Voices of Employees

A content production company was experiencing inefficiencies in its contract-related operations. Below are some specific comments from the field:

1. Content Producer’s Voice.

   • “Every time I sign a contract, I have to explain it in person, which makes it hard for me to focus on other creative tasks.”
   • “Negotiating contracts with performers takes a lot of time, which often delays the delivery schedule.”

2. Voice of the Legal Team

   • “I spend a lot of time drafting and reviewing contracts, which interferes with my other work.”
   • “We don’t have enough storage space for paper contracts, and it’s hard to find past contracts.”

3. Contractor (Performer) Comments.

   • “In-person contract explanations are not always scheduled and it takes a long time to get a contract signed.”
   • “It is burdensome to make multiple visits to sign or revise contracts.”

Project Background and Objectives

As these problems accumulated, employee overtime increased and overall company efficiency declined. To improve the situation, a project was launched to systemize contract-related operations. The objectives are as follows:

• Increase efficiency: Streamline the process of creating, reviewing, and storing contracts to reduce the burden on employees.
• Time Reduction: Reduce the amount of time required to close a contract by reducing the number of in-person contract explanations.
• Reduce Costs: Reduce storage space for paper contracts and lower administrative costs.

Step 1: Gather all interested parties

Selecting and Convening Stakeholders

Gather all stakeholders involved in the project. Specifically, convene the parties involved in the following roles:

• Content Producer: Determine the content and decide what items are required in the contract.
• Legal team: drafts contracts and performs legal checks.
• IT Engineer: responsible for designing and developing the system.

Organize a workshop

The next step is to bring these experts together for a workshop. The purpose of the workshop is for each person to explain his or her work and to deepen mutual understanding.

Step 2: Discuss business processes one at a time

Identify current processes

Identify current business processes. Specific processes may include the following:

1. Content creator determines the content and decides what items are required in the contract (performance fee, duration of distribution, content of performance).
2. the legal team prepares a contract based on this information
3. the contractor reviews the contract and decides whether or not to sign it.
4. Legal team checks and keeps the signed contract.

Identifying Problems

Identify problems in the current process. For example:

• Explaining and signing contracts in person takes time.
• Space is needed for paper storage of contracts.
• It is difficult to revise the contract if it is incomplete.

Step 3: Create an Entity and Interaction Diagram

Identifying Entities

Identify the key entities involved in the business process. The following entities are considered here:

• Content: Information about the work or program to be produced.
• Contract: A document that describes the fee for the performance and the duration of the distribution.
• Performer: The person who is the subject of the contract.
• Legal team: prepares and manages the contract.

Create an illustration of entouragement

Step 4: Identify bounded contexts

Identifying different concepts with the same name

If the term “contract” refers to both the legal team’s working document and the final document that the performer signs, distinguish between them.

Defining Contexts

Define which context each entity belongs to. This makes it clear that entities with the same name have different roles. For example:

Step 5: Record the model as a living document

Recording the model

Record the model as a document based on the entity and interaction diagrams you have created. This model will serve as a living document of the system and will be continuously updated.

Examples of documents to be recorded

1. Ubiquitous Language Dictionary 2.
   2.Entity Diagram 3.
   3.Context map 4.
2. sequence diagram

Save to shared space

Save models to a shared space and make them accessible to the entire team. This allows you to work with the most up-to-date model at all times.

Step 6: Develop Budget and Schedule

Develop a budget

Develop a budget for system development. Factors to consider include:

• Development Costs: IT engineer labor costs, software licensing costs, etc.
• Hardware costs: server and cloud service costs.
• Testing: Cost of building the testing environment and conducting the testing.

Schedule Development

Develop a schedule for the project. The plan is divided into the following phases:

• Requirement Definition: Confirm business process and determine system requirements.
• Design: System architecture design and modeling.
• Development: System implementation.
• Testing: Testing and modifying the system.
• Release: Deployment and implementation of the system.

Step 7: Convert the model to a system

Transition to System Development

Actual development is performed based on the model you have created. Possible required functions include the following:

• Content data registration and editing function: Content creators can register and edit content information.
• Contract creation function: Legal team can automatically generate contracts.
• Interface with e-signature service: Allows subscribers to sign contracts online.
• Contract Alert Function: Notification when a contract is not completed.

Sequence diagram after system migration.

Testing and Deployment

Once development is complete, test and deploy the system to ensure there are no problems.

Summary

This article has described the specific steps in DDD before moving on to development; the essence of DDD is to understand the business process in depth and to systematically leverage the knowledge of experts to build a model. Through this process, we felt that we have the potential to design a system that is not just a technical solution, but one that fundamentally solves a business problem. I would like to continue learning to create more valuable software.