Every time I review a DFD, I see the same failure: a single diagram attempts to show both how a customer places an order and how the backend API validates it. That\u2019s the single biggest source of confusion in real-world data modeling. It\u2019s exhausting to explain why a process like \u201cValidate Order\u201d includes cloud function deployments, and why a business stakeholder can\u2019t understand a field named \u201cpayload.\u201d The fix isn\u2019t more detail\u2014it\u2019s a simple shift: separate the business flow from the technical implementation.<\/p>\n
This chapter shows you how to stop mixing business and technical DFD scope. You\u2019ll learn to build two complementary views: one focused on what happens to data from the user\u2019s perspective, and another that reveals how it moves through servers, queues, and services. The result? A clear, traceable, and stakeholder-friendly model that avoids rework and miscommunication.<\/p>\n
When business analysts blend high-level logic with low-level system actions, they create a “black box” that serves no one well.<\/p>\n
Business stakeholders see technical jargon and give up. Engineers see business processes without sufficient engineering context. The diagram becomes a liability, not a tool.<\/p>\n
I\u2019ve seen this in healthcare systems where a \u201cProcess Patient Referral\u201d node includes Kafka topics, retry mechanisms, and microservice endpoints. That\u2019s not a data flow\u2014those are deployment artifacts.<\/p>\n
These aren\u2019t mistakes in logic\u2014they\u2019re symptoms of a deeper problem: lack of scope separation.<\/p>\n
The key is to treat the business DFD and technical DFD as two views of the same system, not competing models.<\/p>\n
Build a Level 0 DFD focused on the user\u2019s journey, not the system\u2019s architecture.<\/p>\n
Use real business events: \u201cCustomer submits order\u201d, \u201cPayment confirmed\u201d, \u201cShipment dispatched\u201d.<\/p>\n
Keep it simple. No mention of servers, queues, or APIs. The goal is to answer: \u201cWhat does the customer care about?\u201d<\/p>\n
Create a separate Level 0 (or Level 1) DFD using the same processes but from a system perspective.<\/p>\n
Replace \u201cCustomer submits order\u201d with \u201cValidate order payload via API gateway\u201d.<\/p>\n
Now you can show how that input moves through: authentication, validation, message queue, and persistence.<\/p>\n
Use a simple traceability table to show how business events map to technical processes.<\/p>\n
| Business Event<\/th>\n | Technical Process<\/th>\n | Source<\/th>\n<\/tr>\n |
|---|---|---|
| Customer submits order<\/td>\n | API Gateway receives POST \/orders<\/td>\n | Order Service<\/td>\n<\/tr>\n |
| Payment confirmed<\/td>\n | Process payment via Stripe webhook<\/td>\n | Payment Microservice<\/td>\n<\/tr>\n |
| Shipment dispatched<\/td>\n | Trigger logistics notification via RabbitMQ<\/td>\n | Shipping Service<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n This isn\u2019t just documentation\u2014it\u2019s a living map. When requirements change, both views stay aligned.<\/p>\n<\/h3>\n Patterns for Clear Separation<\/h2>\nUse these patterns to ensure your diagrams are mutually reinforcing, not redundant.<\/p>\n Pattern 1: Business DFD = Customer Journey<\/h3>\nModel only what the user or business actor sees.<\/p>\n Examples:<\/p>\n
|