Advanced 40 min read

Design the Architecture

By the end of this lesson, you'll be able to:

Design a data model spanning three departments around a shared Project object
Choose which of Module 43's architectural layers this project actually needs
Write a brief technical design document per Module 41's template

Prerequisites: "Gather Requirements"

The data model

Project__c
  Name, Account__c (Lookup), Status__c, Health__c (Picklist)

Milestone__c
  Project__c (Lookup), Due_Date__c, Status__c

Time_Entry__c
  Project__c (Lookup), Hours__c, Logged_By__c

Support_Case__c  (extends the standard Case-style idea from Module 30)
  Project__c (Lookup), Priority__c, Status__c

Project__c is the shared hub Lesson 1 identified — every other object relates back to it, which is exactly what makes a single, real-time, cross-departmental dashboard possible.

Choosing the architecture deliberately, not by default

This project has four related objects, several trigger-bearing objects, an async health-recalculation job, and an external notification integration — genuinely more moving parts than Module 42\'s banking system. Module 43\'s closing lesson warned against overengineering a small project; this is the opposite case, where the full layered architecture (service, selector, domain/trigger handler) is justified precisely because the codebase is large enough that Lesson 1\'s "Why Architecture Matters at Scale" pain points would otherwise show up quickly.

A brief technical design document

# Technical Design: Project Delivery Tracker

## Approach
Layered architecture (Module 43): ProjectSelector, ProjectService,
MilestoneTriggerHandler, etc. Async health recalculation via
Queueable (Module 38). Slack notification integration via callout
(Module 36).

## Data Model
Project__c as central hub; Milestone__c, Time_Entry__c,
Support_Case__c all relate back to it (see data model above).

## Edge Cases
Multiple departments modifying the same Project__c concurrently;
a Milestone becoming overdue while its Project is already Closed.

## Testing Plan
Bulk-safe trigger tests, service-layer unit tests with dependency
injection (Module 43), async job tests (Module 31/38).

This is Module 41\'s exact TDD template, applied one final time — the same discipline that shaped every project since Module 26, now scoped to the largest project in the course.

Exercise

As a comment, explain why Project__c is designed as the central hub that Milestone__c, Time_Entry__c, and Support_Case__c all relate back to, rather than each department having its own separate top-level object.

Show hint

Think back to Lesson 1's dashboard requirement.

APEX

Design the Architecture Quiz

1. Why is using Module 43's full layered architecture justified for this project, when Module 43 itself warned against overengineering?

This project's actual scale (multiple objects, async processing, integrations) is large enough that the architecture solves real, present pain points, not hypothetical future ones Overengineering warnings never actually apply to any real project The layered architecture is required by Salesforce for any multi-object data model Module 43's warning was a mistake that this project ignores

My Notes

Questions about this lesson

No questions yet — be the first to ask.

Summary

This lesson designs both the data model and the code architecture together — a genuinely multi-object data model, and a deliberate choice to use Module 43's full layered architecture, justified by this project's actual scale rather than adopted by default.

← Gather Requirements Build the Domain Layer →