Configuration is data that selects concrete application behavior without embedding implementation-specific choices in business logic. It can control initialization, runtime operation, or the reporting channel used by an application. section 4.1.1 section 13.2.1
A scalable design keeps general domain and implementation code independent from concrete vendors, devices, or communication mechanisms. Configuration belongs at the application boundary, where it selects and constructs the appropriate implementation. section 4.1.1 section 13.2.1
Use configuration to preserve these boundaries:
- Represent concrete devices, components, and networks as data in an assets-level scope rather than hard-coding vendor names into implementation modules. section 4.1.1
- Choose the reporting channel at application startup through a command-line argument or external application configuration file. section 13.2.1
- Create the selected implementation once and inject it through a functional interface, keeping business functions agnostic about HTTP, TCP, or other transport details. section 13.2.1
- Treat initialization, graceful shutdown, configuration, and global application state as application-level concerns in the architecture. section 3.2.3
Selecting a reporting channel
A reporting function can accept an abstract reporting interface instead of knowing its transport. Startup reads a command-line argument or external configuration file, constructs the matching implementation, and passes it to reportMeteor. The business logic then sends meteors and processes responses without depending on the selected channel. section 13.2.1
Figure 3.13 Architecture diagram for the Andromeda Control Software
Use the architecture diagram to locate configuration alongside initialization, graceful shutdown, and global application state. section 3.2.3
