7. Data Flow Diagram_Architecture

GiveHope Platform: Data Flow Documentation

7. Data Flow Diagram

Shows how data moves through the entire system from the moment a user interacts with the platform to the moment a response is returned. It maps every input, process, data store read/write, and output across seven core processes — Authentication, Campaign Discovery, Donation Configuration, Payment Processing, Schedule Management, Notification Dispatch, and Admin Operations. This diagram answers the question: where does data come from, how is it transformed, and where does it go?

Diagram: Data Flow Diagram.png

This seventh diagram is a Data Flow Diagram (DFD), specifically a Level 1 or Level 2 DFD. While the Sequence Diagram (Diagram 5) showed the timing of events, this DFD focuses on the transformation of data as it moves through various processes. It maps out how raw input (like a donor's credit card info) is processed, stored, and eventually turned into output (like a Zakat distribution report).

1. Data Sources and Sinks (External Entities)

On the far edges of the diagram, we see the origin and destination points for data:

• Donors/Users: The primary sources of input data (personal details, payment info).

• Payment Gateways (Stripe/PayPal): External sinks that receive payment requests and sources that return transaction tokens.

• Charity Recipients/Causes: The ultimate destination for the processed funds and data.

2. Main Processes (The Transformation Hubs)

The central circles or rounded boxes represent the "work" being done. In this specific platform, the data undergoes several critical transformations:

• Validation & Sanitization: Before data hits the database, it is "cleaned" to ensure it meets security standards.

• Donation Routing: This is a complex logic gate where the system determines if a donation is Zakat, Sadaqah, or a Platform Tip. This process calculates the split and directs the data toward different ledger entries.

• Receipt Generation: A process that takes transaction data and "merges" it with a template to create a PDF.

3. Data Stores (The Resting Places)

The open-ended rectangles or parallel lines represent data at rest:

• Transaction Logs: For audit trails.

• Donor Profiles: For CRM and history tracking.

• Campaign Progress: A store that is constantly updated by the "Donation Routing" process to show real-time fundraising totals.

4. Key Data Flows (The "Liquid" Data)

The arrows represent the actual data "packets" moving between processes:

• Payment Tokens: Moving from the Payment Gateway process back into the Donation Service.

• Notification Triggers: Data packets containing Email_ID and Template_Type moving toward the Notification Service.

• Audit Metadata: High-level data moving into the Admin logging system to ensure every dollar is accounted for.

🏗️ Data Flow Phase Evaluation: The "Audit Trail" Audit

This Data Flow Diagram (DFD) is the "Legal & Compliance" map of your architecture. For a Zakat-based charity, this is your most important tool for financial auditing and GDPR/Data Privacy compliance.

1. Data Minimization (Privacy by Design)

• The Strength: You identified "Validation & Sanitization" as a primary process.

• The "Perfect Build" Check: Ensure the DFD shows that PII (Personally Identifiable Information) only flows to the Donor Profile and Receipt Generation processes, and is not passed to the Campaign Discovery or public-facing analytics.

• Developer Note: "Implement Field-Level Encryption for PII. The data should be encrypted as it flows into the Donor Profile store so that even if the database is leaked, names and addresses remain unreadable."

2. The "Donation Routing" Transformation (The Zakat Brain)

• The Strength: Identifying this as a "Transformation Hub" is critical. Raw currency enter, and categorized data exits.

• The "Perfect Build" Check: This process must produce an immutable log. Once the "Donation Routing" process assigns a category (Zakat vs. Sadaqah), the resulting data packet should be "locked" before it hits the Transaction Logs.

• Developer Note: "The Donation Routing process must use Idempotent Keys. If the same data packet enters the process twice, it must output the exact same split-calculation to prevent double-counting or rounding discrepancies."

3. The "Notification Dispatch" Sink

• The Strength: You’ve correctly separated the "Receipt Generation" from the "Notification Dispatch."

• The "Perfect Build" Check: The DFD should show a "Data Sink" for Bounced Emails. If a receipt fails to reach a donor, that data must flow back into an Admin Operations dashboard.

• Developer Note: "We need a 'Dead Letter Queue' flow. If the Notification Dispatch fails, the data packet must be sent to an Admin Review store so staff can manually intervene."

🛠️ Data Integrity & Privacy Checklist

📝 The Ultimate "Notes for Developers" Summary

You have now reviewed seven distinct layers of architecture. To make this "perfectly built," you should present these to your developers as a Unified Technical Specification.

• Context & HLA: Use these for the Project Kickoff to ensure everyone understands the scope.

• Component & Sequence: Use these for the Sprints/Coding Phase to guide how the logic is written.

• ERD & DFD: Use these for the Security & Compliance Review to satisfy auditors and legal teams.

• Deployment: Use this for the Launch/DevOps Phase to set up the servers.