What it shows:
The internal structural blueprint of a custom-built software application. It details the specific code modules, classes, microservices, internal APIs, and code repositories. It maps how the actual software logic is constructed and managed under the hood.
Why it’s needed:
Developer guidance and code maintainability. For custom builds, this serves as the blueprint for the software engineering team. It prevents “spaghetti code” by defining strict modular boundaries. It also proves to the customer’s IT teams that the custom code integrates with CI/CD pipelines and version control standards.
When to use it:
Highly recommended for Custom Application Development, building bespoke API gateways, or writing complex automation/scripting engines. If the delivery team is compiling code/scripts, pushing to a Git repository, and managing software releases, this diagram is required.
When NOT to use it:
Generally best to omit for COTS deployments. The internal source code of vendor-packaged software is not modified or designed.
Example:
