By doing this, we separate relations that are “always true” when deploying an architecture from relations that are “always true” when the architecture is actually running. For example, when diagramming dependency relations of a system, we can (and should) split up run-time dependencies and deploy-time dependencies. “Always true” should really be “always true from a given perspective”. If the diagram includes contextual elements, this information is also conveyed in an unobtrusive way. Note that these transitive relations can extend multiple levels and cross context layers.Īdditionally, when viewed as a diagram, the scope of these relations is easily read by the viewer. Finding such transitive relations is easier in a diagram than text: If another resource X invokes Lambda getIlograph, then X has a transitive relation on DynamoDB table Permissions. Viewers can quickly trace the relations in the diagram to find transitive relations. The diagrams do not need to be read in any order, and they have no start or end.ĭescribing these relations visually in a diagram offers benefits over describing them in text. Unlike sequence diagrams (discussed below), there is no “arrow of time”. It merely tells us that the relation between these components exists: The below diagram doesn’t detail when or how getIlograph reads from Permissions. “Lambda getIlograph reads from DynamoDB table Permissions” is an example of an invariant relation. Relation diagrams come in many forms, but are usually as simple as boxes (components) with labeled arrows going between them (relations). Common relations include dependency, ownership, belonging, unitilization, and capability. Relation diagrams describe the invariant relations between components in a system - that is, relations between components that are always true. We do this to limit the scope of this article, certainly, but it is also in line with the commonly (if vaguely) understood meaning of “architecture diagram”. This restriction excludes popular (and useful) diagrams like flow charts and state machine diagrams. ![]() We’re limiting the definition of architecture diagrams to be only those that include components as defined above. It excludes intangible things like decisions, use cases, states, and actions, as well as indiscrete resources like money and time.Īn architecture diagram of a distributed load testing system running on Amazon Web Services Components may vary in importance, but generally a component is something that is required in order for a system to run properly.īy this definition, components include machines, artifacts, services, repositories, databases, clases, functions, teams, and people, among many others. “An architectural diagram is a diagram of a system that is used to abstract the overall outline of the software system and the relationships, constraints, and boundaries between components.”Ĭomponents are commonly understood to be discrete, tangible, and bounded resources that provide value to a system. First, what is an architecture diagram?īefore continuing, we must first define “architecture diagram”. Understanding both is critical for creating clear, informative, and relevant architecture diagrams for technical systems. ![]() Together they form a duality their purposes and capabilities are opposite and complementary. There are two fundamental types of architecture diagrams from which all others derive.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |