Case Study - Domain Driven Design Architecture
Problem Statements:
-
10 applications each within its' own disparate system does not share data when they should
-
Old architecture makes it very costly to deploy to production
-
Customizations or updates to one or more applications routinely break other applications
Background
I was brought in by a large data company to guide them through a re-architecture of 10 legacy applications. These applications were purchased by the company years prior. Once they owned these applications, very little was done over the years to upgrade the technology that was originally developed to create the apps.
​
These applications were used as a Saas for large to medium sized companies to onboard and offboard employees. A few examples of the applications as part of the suite were an I9 form, tax forms, workers' compensation forms, employee manuals, etc.
​
The issues with these applications were far reaching from inconsistent data, no data sharing, and performance issues. Since many of their clients needed customizations to these applications, the current architecture made it very difficult to deliver clean, timely and accurate production deployments.
​
Thinking Through the Problem
The company had an architecture in mind when the project started. They believed a domain driven design architecture made sense because although there was a lot of data that needed to be captured within these applications, the data itself was not overly complex. Each application was its' own entity currently so if an employee was to begin the onboarding process, the employee had to log into several applications, and fill out the forms separately. The employee would need to re-enter their name, address, social security number, phone number, etc., on each form. This caused data inconsistencies because many times the employee would make a typo on one or more of the forms which led to the same human having multiple phone numbers, social security numbers, etc.
​
Thinking through how to solve these issues, I believed the best approach was to create a workflow-based application where an employee would log in, enter their data, and that data would then display on other forms where appropriate. However, the way these applications were currently developed would not allow for that unless a new approach to the architecture was implemented. Using domain driven design as a guide, my job was to identify the business domains across these 10 applications, then identify sub-domains, bounded contexts and eventually work with the development team to carve out microservices.
Requirements Process
Each application had its' own SME on the business side along with a lead developer. Since I was dealing with 10 applications, the first thing I needed to understand was the purpose of each application. To accomplish this, I set up a series of meetings first with each SME. Since domain driven design is based on business domains, this was the most important piece. I first had each SME give me a demo of the application and explain at a high to medium level the data and how the data is used within each.
​
During each session I had a list of questions prepared that would help guide both the SME and myself to what the desired outcome would be. Each SME emphasized the importance of the following:
​
-
The same piece of data for a person should be shared across applications where applicable (no need to re-enter the same data elements)
-
Applications that were used for onboarding should be all part of a single workflow
-
Applications that were used for offboarding should be all part of a single workflow
-
There must be data validation in certain fields (i.e., a phone number, social security number must be numeric only and with the correct character count)
-
A workflow must have an auto-save feature where data is saved (an employee does not have to start the entire workflow over if the application has a hiccup)
​
In order to meet these requirements, I needed to first get sign-off from stakeholders on what the business domains were along with the sub-domains in each domain. I created many workflow and process diagrams along with context maps that showed how data would flow between each workflow.
The Solution
Since this project was to suggest and document a new architecture, the first piece was to provide a proof of concept that a microservice architecture would work per the requirements. It was at this time I had a senior developer and microservice expert begin to develop a POC for a single domain. Due to security concerns for the nature of the data, we were given specific tech stacks that were allowed to be used.
​
I began by mapping out the onboarding domain using sub-domains as the microservices to be used. The developers then took that, utilized the microservices suggested, along with incorporating the tech stack(s) needed for each based on security level required for each microservice. A series of demonstrations was shown to stakeholders throughout the POC to receive feedback and to avoid any potential issues before getting too far down the path.
Even though the goal was to prove this new architecture would work, our job was not to build the entire solution. Once we were confident the POC was working, I then documented in great detail how the remaining domains/sub-domains would all fit together to allow for an easy handoff to their development team.
The Result
I was able to prove that a microservice architecture would work using a workflow based model. Using a workflow based model, they would no longer have 10 applications; they would simply have a series of workflows using this new architecture. By using a microservice architecture, it would allow much easier deployments and deployments would be into QA, UAT and Production much quicker. A big part of this new architecture was to decouple so much custom code from the base code.
​
At the end of the project I had completed all of the documentation needed for their developers to follow the 'guide' on how to take the POC into real development that would meet the requirements from the stakeholders.