Concept and mechanism
An Application Component describes a software unit organized around implementation. An Application Function describes automated behavior that component can perform. An Application Service represents behavior exposed for use. The distinction shows why replacing a component need not change the service contract. A Data Object describes structured data for automated processing. One business concept may have several technical representations; similar names guarantee neither identity nor equal semantics. When reading a model, inspect relationships connecting the performer, behavior, offered service, and used data. Do not assume those connections simply because boxes appear close together.
Guided application
In a fictional example, a positions component performs the calculate-position function and exposes a query service. The function reads instructions and writes results. One view may show only the service and consumers; another may show data and implementation. Retain the same identity for shared elements across views. If two systems call different values available position, document the distinction and validate the contract with consumers. An Access relationship showing reading does not assert writing permission; conversely, the model does not configure actual permissions. Use it to guide questions and verify implementation. The application layer makes dependencies discussable before replacement or migration affects the business service.
Component, calculation function, and query service describe different aspects.
Common pitfalls
Component treated as service; equal name treated as equal data; model treated as access configuration.
Related topics: Language, model, and aspects · Relationships, direction, and meaning · Motivation and strategy
Read behavior and data before concluding change impact.
Reference: Archi hint: application function · OGA-031; ArchiMate 3.2