Software Architecture

"survey_id"
:

"19999"
,

"created_date"
:

"Dec 28 2021"

,


"description"
:

"Survey to gauge customer..."

,


"questions"
:

[

{


"question_id"
:

"50001"
,

"question"
:

"Rate the expert"

,


"answer_type"
:

"Option"
,

"answer_options"
:

"1,2,3,4,5"

,


"order"
:

"2"

},

{

"question_id"
:

"50000"
,

"question"
:

"Did the expert fix the problem?"

,


"answer_type"
:

"Boolean"

,


"answer_options"
:

"Yes,No"
,

"order"
:

"1"

}

]

}

“I really like that approach,” said Skyler. “Essentially, I wouldn’t have to worry so much about aggregating things myself in the user interface, meaning I could simply render the document I retrieve on the web page.”

“Yeah,” said Devon, “but it would require additional work on the database side as questions would be replicated in each survey document. You know, the whole reuse argument. Here, let me show you the other approach.”
Skyler explained that another way to think about aggregates was to split the survey and question model so that the questions could be operated on in an independent fashion, as shown in Figure 6-37, with the corresponding source code listing in Example 6-4. This would allow the same question to be used in multiple surveys, but would be harder to render and retrieve than the single aggregate.

Figure 6-37. Survey model with multiple aggregates with references

Example 6-4. JSON document with aggregates split and parent document showing references to children
#

Survey

aggregate

with

references

to

Questions

{

"survey_id"

:

"19999"
,

"created_date"

:

"Dec 28"
,

"description"

:

"Survey to gauge customer..."

,

"questions"

:

[

{
"question_id"
:

"50001"
,

"order"
:

"2"
},

{
"question_id"

:

"50000"
,

"order"
:

"1"
}

]

}

#

Question

aggregate

{

"question_id"
:

"50001"
,

"question"

:

"Rate the expert"

,

"answer_type"

:

"Option"
,

"answer_options"

:

"1,2,3,4,5"

}

{

"question_id"
:

"50000"
,

"question"

:

"Did the expert fix the problem?"

,

"answer_type"

:

"Boolean"

,

"answer_options"

:

"Yes,No"

}

Because most of the complexity and change issues were in the user interface, Skyler liked the single aggregate model better. Devon liked the multiple aggregate to avoid duplication of question data in each survey. However, Addison pointed out that there were only five survey types (one for each product category), and that most of the changes involved adding or removing questions. The team discussed the trade-offs, and all agreed that they were willing to trade off some duplication of question data for the ease of changes and rendering on the user interface side. Because of the difficulty of this decision and the structural nature of changing the data, Addison created an ADR to record the justifications of this decision:

ADR: Use of Document Database for Customer Survey
Context
Customers receive a survey after the work has been completed by the customer, which is rendered on a web page for the customer to fill out and submit. The customer receives one of five survey types based on the type of electronic product fixed or installed. The survey is currently stored in a relational database, but the team wants to migrate the survey to a document database using JSON.