{"id":25205956,"url":"https://github.com/cesarparra/arc42-template","last_synced_at":"2026-02-06T20:31:34.926Z","repository":{"id":276101912,"uuid":"679677229","full_name":"cesarParra/arc42-template","owner":"cesarParra","description":null,"archived":false,"fork":false,"pushed_at":"2023-08-17T11:25:03.000Z","size":371,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-11-16T00:27:39.632Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/cesarParra.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-08-17T11:22:03.000Z","updated_at":"2023-08-17T11:22:04.000Z","dependencies_parsed_at":"2025-02-06T09:47:01.350Z","dependency_job_id":"02aea3d2-f957-4610-a471-01cce6d5b750","html_url":"https://github.com/cesarParra/arc42-template","commit_stats":null,"previous_names":["cesarparra/arc42-template"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/cesarParra/arc42-template","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cesarParra%2Farc42-template","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cesarParra%2Farc42-template/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cesarParra%2Farc42-template/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cesarParra%2Farc42-template/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/cesarParra","download_url":"https://codeload.github.com/cesarParra/arc42-template/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cesarParra%2Farc42-template/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29175211,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-06T20:14:21.878Z","status":"ssl_error","status_checked_at":"2026-02-06T20:14:21.443Z","response_time":59,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-02-10T10:34:49.771Z","updated_at":"2026-02-06T20:31:34.911Z","avatar_url":"https://github.com/cesarParra.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# \n\n**About arc42**\n\narc42, the template for documentation of software and system\narchitecture.\n\nTemplate Version 8.2 EN. (based upon AsciiDoc version), January 2023\n\nCreated, maintained and © by Dr. Peter Hruschka, Dr. Gernot Starke and\ncontributors. See \u003chttps://arc42.org\u003e.\n\n\u003cdiv class=\"note\"\u003e\n\nThis version of the template contains some help and explanations. It is\nused for familiarization with arc42 and the understanding of the\nconcepts. For documentation of your own system you use better the\n*plain* version.\n\n\u003c/div\u003e\n\n# Introduction and Goals\n\nDescribes the relevant requirements and the driving forces that software\narchitects and development team must consider. These include\n\n-   underlying business goals,\n\n-   essential features,\n\n-   essential functional requirements,\n\n-   quality goals for the architecture and\n\n-   relevant stakeholders and their expectations\n\n## Requirements Overview\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Contents**\n\n\u003c/div\u003e\n\nShort description of the functional requirements, driving forces,\nextract (or abstract) of requirements. Link to (hopefully existing)\nrequirements documents (with version number and information where to\nfind it).\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\nFrom the point of view of the end users a system is created or modified\nto improve support of a business activity and/or improve the quality.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Form**\n\n\u003c/div\u003e\n\nShort textual description, probably in tabular use-case format. If\nrequirements documents exist this overview should refer to these\ndocuments.\n\nKeep these excerpts as short as possible. Balance readability of this\ndocument with potential redundancy w.r.t to requirements documents.\n\nSee [Introduction and Goals](https://docs.arc42.org/section-1/) in the\narc42 documentation.\n\n## Quality Goals\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Contents**\n\n\u003c/div\u003e\n\nThe top three (max five) quality goals for the architecture whose\nfulfillment is of highest importance to the major stakeholders. We\nreally mean quality goals for the architecture. Don’t confuse them with\nproject goals. They are not necessarily identical.\n\nConsider this overview of potential topics (based upon the ISO 25010\nstandard):\n\n![Categories of Quality\nRequirements](images/01_2_iso-25010-topics-EN.drawio.png)\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\nYou should know the quality goals of your most important stakeholders,\nsince they will influence fundamental architectural decisions. Make sure\nto be very concrete about these qualities, avoid buzzwords. If you as an\narchitect do not know how the quality of your work will be judged…\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Form**\n\n\u003c/div\u003e\n\nA table with quality goals and concrete scenarios, ordered by priorities\n\n## Stakeholders\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Contents**\n\n\u003c/div\u003e\n\nExplicit overview of stakeholders of the system, i.e. all person, roles\nor organizations that\n\n-   should know the architecture\n\n-   have to be convinced of the architecture\n\n-   have to work with the architecture or with code\n\n-   need the documentation of the architecture for their work\n\n-   have to come up with decisions about the system or its development\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\nYou should know all parties involved in development of the system or\naffected by the system. Otherwise, you may get nasty surprises later in\nthe development process. These stakeholders determine the extent and the\nlevel of detail of your work and its results.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Form**\n\n\u003c/div\u003e\n\nTable with role names, person names, and their expectations with respect\nto the architecture and its documentation.\n\n| Role/Name   | Contact        | Expectations       |\n|-------------|----------------|--------------------|\n| *\\\u003cRole-1\u003e* | *\\\u003cContact-1\u003e* | *\\\u003cExpectation-1\u003e* |\n| *\\\u003cRole-2\u003e* | *\\\u003cContact-2\u003e* | *\\\u003cExpectation-2\u003e* |\n\n# Architecture Constraints\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Contents**\n\n\u003c/div\u003e\n\nAny requirement that constraints software architects in their freedom of\ndesign and implementation decisions or decision about the development\nprocess. These constraints sometimes go beyond individual systems and\nare valid for whole organizations and companies.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\nArchitects should know exactly where they are free in their design\ndecisions and where they must adhere to constraints. Constraints must\nalways be dealt with; they may be negotiable, though.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Form**\n\n\u003c/div\u003e\n\nSimple tables of constraints with explanations. If needed you can\nsubdivide them into technical constraints, organizational and political\nconstraints and conventions (e.g. programming or versioning guidelines,\ndocumentation or naming conventions)\n\nSee [Architecture Constraints](https://docs.arc42.org/section-2/) in the\narc42 documentation.\n\n# System Scope and Context\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Contents**\n\n\u003c/div\u003e\n\nSystem scope and context - as the name suggests - delimits your system\n(i.e. your scope) from all its communication partners (neighboring\nsystems and users, i.e. the context of your system). It thereby\nspecifies the external interfaces.\n\nIf necessary, differentiate the business context (domain specific inputs\nand outputs) from the technical context (channels, protocols, hardware).\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\nThe domain interfaces and technical interfaces to communication partners\nare among your system’s most critical aspects. Make sure that you\ncompletely understand them.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Form**\n\n\u003c/div\u003e\n\nVarious options:\n\n-   Context diagrams\n\n-   Lists of communication partners and their interfaces.\n\nSee [Context and Scope](https://docs.arc42.org/section-3/) in the arc42\ndocumentation.\n\n## Business Context\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Contents**\n\n\u003c/div\u003e\n\nSpecification of **all** communication partners (users, IT-systems, …)\nwith explanations of domain specific inputs and outputs or interfaces.\nOptionally you can add domain specific formats or communication\nprotocols.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\nAll stakeholders should understand which data are exchanged with the\nenvironment of the system.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Form**\n\n\u003c/div\u003e\n\nAll kinds of diagrams that show the system as a black box and specify\nthe domain interfaces to communication partners.\n\nAlternatively (or additionally) you can use a table. The title of the\ntable is the name of your system, the three columns contain the name of\nthe communication partner, the inputs, and the outputs.\n\n**\\\u003cDiagram or Table\u003e**\n\n**\\\u003coptionally: Explanation of external domain interfaces\u003e**\n\n## Technical Context\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Contents**\n\n\u003c/div\u003e\n\nTechnical interfaces (channels and transmission media) linking your\nsystem to its environment. In addition a mapping of domain specific\ninput/output to the channels, i.e. an explanation which I/O uses which\nchannel.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\nMany stakeholders make architectural decision based on the technical\ninterfaces between the system and its context. Especially infrastructure\nor hardware designers decide these technical interfaces.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Form**\n\n\u003c/div\u003e\n\nE.g. UML deployment diagram describing channels to neighboring systems,\ntogether with a mapping table showing the relationships between channels\nand input/output.\n\n**\\\u003cDiagram or Table\u003e**\n\n**\\\u003coptionally: Explanation of technical interfaces\u003e**\n\n**\\\u003cMapping Input/Output to Channels\u003e**\n\n# Solution Strategy\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Contents**\n\n\u003c/div\u003e\n\nA short summary and explanation of the fundamental decisions and\nsolution strategies, that shape system architecture. It includes\n\n-   technology decisions\n\n-   decisions about the top-level decomposition of the system, e.g.\n    usage of an architectural pattern or design pattern\n\n-   decisions on how to achieve key quality goals\n\n-   relevant organizational decisions, e.g. selecting a development\n    process or delegating certain tasks to third parties.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\nThese decisions form the cornerstones for your architecture. They are\nthe foundation for many other detailed decisions or implementation\nrules.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Form**\n\n\u003c/div\u003e\n\nKeep the explanations of such key decisions short.\n\nMotivate what was decided and why it was decided that way, based upon\nproblem statement, quality goals and key constraints. Refer to details\nin the following sections.\n\nSee [Solution Strategy](https://docs.arc42.org/section-4/) in the arc42\ndocumentation.\n\n# Building Block View\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Content**\n\n\u003c/div\u003e\n\nThe building block view shows the static decomposition of the system\ninto building blocks (modules, components, subsystems, classes,\ninterfaces, packages, libraries, frameworks, layers, partitions, tiers,\nfunctions, macros, operations, data structures, …) as well as their\ndependencies (relationships, associations, …)\n\nThis view is mandatory for every architecture documentation. In analogy\nto a house this is the *floor plan*.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\nMaintain an overview of your source code by making its structure\nunderstandable through abstraction.\n\nThis allows you to communicate with your stakeholder on an abstract\nlevel without disclosing implementation details.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Form**\n\n\u003c/div\u003e\n\nThe building block view is a hierarchical collection of black boxes and\nwhite boxes (see figure below) and their descriptions.\n\n![Hierarchy of building blocks](images/05_building_blocks-EN.png)\n\n**Level 1** is the white box description of the overall system together\nwith black box descriptions of all contained building blocks.\n\n**Level 2** zooms into some building blocks of level 1. Thus it contains\nthe white box description of selected building blocks of level 1,\ntogether with black box descriptions of their internal building blocks.\n\n**Level 3** zooms into selected building blocks of level 2, and so on.\n\nSee [Building Block View](https://docs.arc42.org/section-5/) in the\narc42 documentation.\n\n## Whitebox Overall System\n\nHere you describe the decomposition of the overall system using the\nfollowing white box template. It contains\n\n-   an overview diagram\n\n-   a motivation for the decomposition\n\n-   black box descriptions of the contained building blocks. For these\n    we offer you alternatives:\n\n    -   use *one* table for a short and pragmatic overview of all\n        contained building blocks and their interfaces\n\n    -   use a list of black box descriptions of the building blocks\n        according to the black box template (see below). Depending on\n        your choice of tool this list could be sub-chapters (in text\n        files), sub-pages (in a Wiki) or nested elements (in a modeling\n        tool).\n\n-   (optional:) important interfaces, that are not explained in the\n    black box templates of a building block, but are very important for\n    understanding the white box. Since there are so many ways to specify\n    interfaces why do not provide a specific template for them. In the\n    worst case you have to specify and describe syntax, semantics,\n    protocols, error handling, restrictions, versions, qualities,\n    necessary compatibilities and many things more. In the best case you\n    will get away with examples or simple signatures.\n\n***\\\u003cOverview Diagram\u003e***\n\nMotivation  \n*\\\u003ctext explanation\u003e*\n\nContained Building Blocks  \n*\\\u003cDescription of contained building block (black boxes)\u003e*\n\nImportant Interfaces  \n*\\\u003cDescription of important interfaces\u003e*\n\nInsert your explanations of black boxes from level 1:\n\nIf you use tabular form you will only describe your black boxes with\nname and responsibility according to the following schema:\n\n| **Name**         | **Responsibility** |\n|------------------|--------------------|\n| *\\\u003cblack box 1\u003e* |  *\\\u003cText\u003e*         |\n| *\\\u003cblack box 2\u003e* |  *\\\u003cText\u003e*         |\n\nIf you use a list of black box descriptions then you fill in a separate\nblack box template for every important building block . Its headline is\nthe name of the black box.\n\n### \\\u003cName black box 1\u003e\n\nHere you describe \\\u003cblack box 1\u003e according the the following black box\ntemplate:\n\n-   Purpose/Responsibility\n\n-   Interface(s), when they are not extracted as separate paragraphs.\n    This interfaces may include qualities and performance\n    characteristics.\n\n-   (Optional) Quality-/Performance characteristics of the black box,\n    e.g.availability, run time behavior, ….\n\n-   (Optional) directory/file location\n\n-   (Optional) Fulfilled requirements (if you need traceability to\n    requirements).\n\n-   (Optional) Open issues/problems/risks\n\n*\\\u003cPurpose/Responsibility\u003e*\n\n*\\\u003cInterface(s)\u003e*\n\n*\\\u003c(Optional) Quality/Performance Characteristics\u003e*\n\n*\\\u003c(Optional) Directory/File Location\u003e*\n\n*\\\u003c(Optional) Fulfilled Requirements\u003e*\n\n*\\\u003c(optional) Open Issues/Problems/Risks\u003e*\n\n### \\\u003cName black box 2\u003e\n\n*\\\u003cblack box template\u003e*\n\n### \\\u003cName black box n\u003e\n\n*\\\u003cblack box template\u003e*\n\n### \\\u003cName interface 1\u003e\n\n…\n\n### \\\u003cName interface m\u003e\n\n## Level 2\n\nHere you can specify the inner structure of (some) building blocks from\nlevel 1 as white boxes.\n\nYou have to decide which building blocks of your system are important\nenough to justify such a detailed description. Please prefer relevance\nover completeness. Specify important, surprising, risky, complex or\nvolatile building blocks. Leave out normal, simple, boring or\nstandardized parts of your system\n\n### White Box *\\\u003cbuilding block 1\u003e*\n\n…describes the internal structure of *building block 1*.\n\n*\\\u003cwhite box template\u003e*\n\n### White Box *\\\u003cbuilding block 2\u003e*\n\n*\\\u003cwhite box template\u003e*\n\n…\n\n### White Box *\\\u003cbuilding block m\u003e*\n\n*\\\u003cwhite box template\u003e*\n\n## Level 3\n\nHere you can specify the inner structure of (some) building blocks from\nlevel 2 as white boxes.\n\nWhen you need more detailed levels of your architecture please copy this\npart of arc42 for additional levels.\n\n### White Box \\\u003c\\_building block x.1\\_\\\u003e\n\nSpecifies the internal structure of *building block x.1*.\n\n*\\\u003cwhite box template\u003e*\n\n### White Box \\\u003c\\_building block x.2\\_\\\u003e\n\n*\\\u003cwhite box template\u003e*\n\n### White Box \\\u003c\\_building block y.1\\_\\\u003e\n\n*\\\u003cwhite box template\u003e*\n\n# Runtime View\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Contents**\n\n\u003c/div\u003e\n\nThe runtime view describes concrete behavior and interactions of the\nsystem’s building blocks in form of scenarios from the following areas:\n\n-   important use cases or features: how do building blocks execute\n    them?\n\n-   interactions at critical external interfaces: how do building blocks\n    cooperate with users and neighboring systems?\n\n-   operation and administration: launch, start-up, stop\n\n-   error and exception scenarios\n\nRemark: The main criterion for the choice of possible scenarios\n(sequences, workflows) is their **architectural relevance**. It is\n**not** important to describe a large number of scenarios. You should\nrather document a representative selection.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\nYou should understand how (instances of) building blocks of your system\nperform their job and communicate at runtime. You will mainly capture\nscenarios in your documentation to communicate your architecture to\nstakeholders that are less willing or able to read and understand the\nstatic models (building block view, deployment view).\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Form**\n\n\u003c/div\u003e\n\nThere are many notations for describing scenarios, e.g.\n\n-   numbered list of steps (in natural language)\n\n-   activity diagrams or flow charts\n\n-   sequence diagrams\n\n-   BPMN or EPCs (event process chains)\n\n-   state machines\n\n-   …\n\nSee [Runtime View](https://docs.arc42.org/section-6/) in the arc42\ndocumentation.\n\n## \\\u003cRuntime Scenario 1\u003e\n\n-   *\\\u003cinsert runtime diagram or textual description of the scenario\u003e*\n\n-   *\\\u003cinsert description of the notable aspects of the interactions\n    between the building block instances depicted in this diagram.\u003e*\n\n## \\\u003cRuntime Scenario 2\u003e\n\n## …\n\n## \\\u003cRuntime Scenario n\u003e\n\n# Deployment View\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Content**\n\n\u003c/div\u003e\n\nThe deployment view describes:\n\n1.  technical infrastructure used to execute your system, with\n    infrastructure elements like geographical locations, environments,\n    computers, processors, channels and net topologies as well as other\n    infrastructure elements and\n\n2.  mapping of (software) building blocks to that infrastructure\n    elements.\n\nOften systems are executed in different environments, e.g. development\nenvironment, test environment, production environment. In such cases you\nshould document all relevant environments.\n\nEspecially document a deployment view if your software is executed as\ndistributed system with more than one computer, processor, server or\ncontainer or when you design and construct your own hardware processors\nand chips.\n\nFrom a software perspective it is sufficient to capture only those\nelements of an infrastructure that are needed to show a deployment of\nyour building blocks. Hardware architects can go beyond that and\ndescribe an infrastructure to any level of detail they need to capture.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\nSoftware does not run without hardware. This underlying infrastructure\ncan and will influence a system and/or some cross-cutting concepts.\nTherefore, there is a need to know the infrastructure.\n\nMaybe a highest level deployment diagram is already contained in section\n3.2. as technical context with your own infrastructure as ONE black box.\nIn this section one can zoom into this black box using additional\ndeployment diagrams:\n\n-   UML offers deployment diagrams to express that view. Use it,\n    probably with nested diagrams, when your infrastructure is more\n    complex.\n\n-   When your (hardware) stakeholders prefer other kinds of diagrams\n    rather than a deployment diagram, let them use any kind that is able\n    to show nodes and channels of the infrastructure.\n\nSee [Deployment View](https://docs.arc42.org/section-7/) in the arc42\ndocumentation.\n\n## Infrastructure Level 1\n\nDescribe (usually in a combination of diagrams, tables, and text):\n\n-   distribution of a system to multiple locations, environments,\n    computers, processors, .., as well as physical connections between\n    them\n\n-   important justifications or motivations for this deployment\n    structure\n\n-   quality and/or performance features of this infrastructure\n\n-   mapping of software artifacts to elements of this infrastructure\n\nFor multiple environments or alternative deployments please copy and\nadapt this section of arc42 for all relevant environments.\n\n***\\\u003cOverview Diagram\u003e***\n\nMotivation  \n*\\\u003cexplanation in text form\u003e*\n\nQuality and/or Performance Features  \n*\\\u003cexplanation in text form\u003e*\n\nMapping of Building Blocks to Infrastructure  \n*\\\u003cdescription of the mapping\u003e*\n\n## Infrastructure Level 2\n\nHere you can include the internal structure of (some) infrastructure\nelements from level 1.\n\nPlease copy the structure from level 1 for each selected element.\n\n### *\\\u003cInfrastructure Element 1\u003e*\n\n*\\\u003cdiagram + explanation\u003e*\n\n### *\\\u003cInfrastructure Element 2\u003e*\n\n*\\\u003cdiagram + explanation\u003e*\n\n…\n\n### *\\\u003cInfrastructure Element n\u003e*\n\n*\\\u003cdiagram + explanation\u003e*\n\n# Cross-cutting Concepts\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Content**\n\n\u003c/div\u003e\n\nThis section describes overall, principal regulations and solution ideas\nthat are relevant in multiple parts (= cross-cutting) of your system.\nSuch concepts are often related to multiple building blocks. They can\ninclude many different topics, such as\n\n-   models, especially domain models\n\n-   architecture or design patterns\n\n-   rules for using specific technology\n\n-   principal, often technical decisions of an overarching (=\n    cross-cutting) nature\n\n-   implementation rules\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\nConcepts form the basis for *conceptual integrity* (consistency,\nhomogeneity) of the architecture. Thus, they are an important\ncontribution to achieve inner qualities of your system.\n\nSome of these concepts cannot be assigned to individual building blocks,\ne.g. security or safety.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Form**\n\n\u003c/div\u003e\n\nThe form can be varied:\n\n-   concept papers with any kind of structure\n\n-   cross-cutting model excerpts or scenarios using notations of the\n    architecture views\n\n-   sample implementations, especially for technical concepts\n\n-   reference to typical usage of standard frameworks (e.g. using\n    Hibernate for object/relational mapping)\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Structure**\n\n\u003c/div\u003e\n\nA potential (but not mandatory) structure for this section could be:\n\n-   Domain concepts\n\n-   User Experience concepts (UX)\n\n-   Safety and security concepts\n\n-   Architecture and design patterns\n\n-   \"Under-the-hood\"\n\n-   development concepts\n\n-   operational concepts\n\nNote: it might be difficult to assign individual concepts to one\nspecific topic on this list.\n\n![Possible topics for crosscutting\nconcepts](images/08-Crosscutting-Concepts-Structure-EN.png)\n\nSee [Concepts](https://docs.arc42.org/section-8/) in the arc42\ndocumentation.\n\n## *\\\u003cConcept 1\u003e*\n\n*\\\u003cexplanation\u003e*\n\n## *\\\u003cConcept 2\u003e*\n\n*\\\u003cexplanation\u003e*\n\n…\n\n## *\\\u003cConcept n\u003e*\n\n*\\\u003cexplanation\u003e*\n\n# Architecture Decisions\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Contents**\n\n\u003c/div\u003e\n\nImportant, expensive, large scale or risky architecture decisions\nincluding rationales. With \"decisions\" we mean selecting one alternative\nbased on given criteria.\n\nPlease use your judgement to decide whether an architectural decision\nshould be documented here in this central section or whether you better\ndocument it locally (e.g. within the white box template of one building\nblock).\n\nAvoid redundancy. Refer to section 4, where you already captured the\nmost important decisions of your architecture.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\nStakeholders of your system should be able to comprehend and retrace\nyour decisions.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Form**\n\n\u003c/div\u003e\n\nVarious options:\n\n-   ADR ([Documenting Architecture\n    Decisions](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions))\n    for every important decision\n\n-   List or table, ordered by importance and consequences or:\n\n-   more detailed in form of separate sections per decision\n\nSee [Architecture Decisions](https://docs.arc42.org/section-9/) in the\narc42 documentation. There you will find links and examples about ADR.\n\n# Quality Requirements\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Content**\n\n\u003c/div\u003e\n\nThis section contains all quality requirements as quality tree with\nscenarios. The most important ones have already been described in\nsection 1.2. (quality goals)\n\nHere you can also capture quality requirements with lesser priority,\nwhich will not create high risks when they are not fully achieved.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\nSince quality requirements will have a lot of influence on architectural\ndecisions you should know for every stakeholder what is really important\nto them, concrete and measurable.\n\nSee [Quality Requirements](https://docs.arc42.org/section-10/) in the\narc42 documentation.\n\n## Quality Tree\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Content**\n\n\u003c/div\u003e\n\nThe quality tree (as defined in ATAM – Architecture Tradeoff Analysis\nMethod) with quality/evaluation scenarios as leafs.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\nThe tree structure with priorities provides an overview for a sometimes\nlarge number of quality requirements.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Form**\n\n\u003c/div\u003e\n\nThe quality tree is a high-level overview of the quality goals and\nrequirements:\n\n-   tree-like refinement of the term \"quality\". Use \"quality\" or\n    \"usefulness\" as a root\n\n-   a mind map with quality categories as main branches\n\nIn any case the tree should include links to the scenarios of the\nfollowing section.\n\n## Quality Scenarios\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Contents**\n\n\u003c/div\u003e\n\nConcretization of (sometimes vague or implicit) quality requirements\nusing (quality) scenarios.\n\nThese scenarios describe what should happen when a stimulus arrives at\nthe system.\n\nFor architects, two kinds of scenarios are important:\n\n-   Usage scenarios (also called application scenarios or use case\n    scenarios) describe the system’s runtime reaction to a certain\n    stimulus. This also includes scenarios that describe the system’s\n    efficiency or performance. Example: The system reacts to a user’s\n    request within one second.\n\n-   Change scenarios describe a modification of the system or of its\n    immediate environment. Example: Additional functionality is\n    implemented or requirements for a quality attribute change.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\nScenarios make quality requirements concrete and allow to more easily\nmeasure or decide whether they are fulfilled.\n\nEspecially when you want to assess your architecture using methods like\nATAM you need to describe your quality goals (from section 1.2) more\nprecisely down to a level of scenarios that can be discussed and\nevaluated.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Form**\n\n\u003c/div\u003e\n\nTabular or free form text.\n\n# Risks and Technical Debts\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Contents**\n\n\u003c/div\u003e\n\nA list of identified technical risks or technical debts, ordered by\npriority\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\n“Risk management is project management for grown-ups” (Tim Lister,\nAtlantic Systems Guild.)\n\nThis should be your motto for systematic detection and evaluation of\nrisks and technical debts in the architecture, which will be needed by\nmanagement stakeholders (e.g. project managers, product owners) as part\nof the overall risk analysis and measurement planning.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Form**\n\n\u003c/div\u003e\n\nList of risks and/or technical debts, probably including suggested\nmeasures to minimize, mitigate or avoid risks or reduce technical debts.\n\nSee [Risks and Technical Debt](https://docs.arc42.org/section-11/) in\nthe arc42 documentation.\n\n# Glossary\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Contents**\n\n\u003c/div\u003e\n\nThe most important domain and technical terms that your stakeholders use\nwhen discussing the system.\n\nYou can also see the glossary as source for translations if you work in\nmulti-language teams.\n\n\u003cdiv class=\"formalpara-title\"\u003e\n\n**Motivation**\n\n\u003c/div\u003e\n\nYou should clearly define your terms, so that all stakeholders\n\n-   have an identical understanding of these terms\n\n-   do not use synonyms and homonyms\n\nA table with columns \\\u003cTerm\u003e and \\\u003cDefinition\u003e.\n\nPotentially more columns in case you need translations.\n\nSee [Glossary](https://docs.arc42.org/section-12/) in the arc42\ndocumentation.\n\n| Term        | Definition        |\n|-------------|-------------------|\n| *\\\u003cTerm-1\u003e* | *\\\u003cdefinition-1\u003e* |\n| *\\\u003cTerm-2\u003e* | *\\\u003cdefinition-2\u003e* |\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcesarparra%2Farc42-template","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcesarparra%2Farc42-template","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcesarparra%2Farc42-template/lists"}