to distinguish between our system and "everything else" and relationship between our system and its environment

explain the STATIC decomposition of system into building blocks (modules, components, subsystems...) & their relationship (interfaces, dependencies, associations...)

DYNAMIC view, interaction between building blocks at runtime

UML sequence diagrams, activity diagrams, object diagrams...

Completeness is NOT a goal or requirement for documentation

Context: what is the issue that we are seeing that is motivating this decision

Decision: what is the change we are proposing

Consequences: what becomes easier or more difficult to do because of this change

• any decisions within software architecture that concern architecturally significant requirements
• hard to take and/or hard to change
• often affect fundamental structure, quality characteristics, external interfaces ...

choices of technologies, structures, pattern, implementation style...

Structure (generic template, specific structure...)

understandability is improved, the structure of documentation is optimized for readability

retrievability, who know the overall structure -> easily find the desired information

re-use appropriate parts of documentation in other systems

the amount and level of detail of documentation needed at each stage of development

formality of documentation (diagrams, simple drawings...)

formal reviews and sign-offs for documenation

start from GENERAL, ABSTRACTION, BIRD'S EYE PERSPECTIVE and step into details

keep things CONSISTENT over various components

Reduce risks

VIEWs focus on specific concerns, parts or aspects of system

repeated cycles (iterations) - delivers or improves part of system

after each iterations, feedback from stakeholders is collected => learning and improvement is based upon this feedback

problems are detected early => more time to resolve

development and rollout activities are performed in every iteration => routine processes and less errors

changes in requirements / technologies can be taken into account

development risks and uncertainties are minimized

approach for developing software for complex application domains

facilitate common understanding of important business terminology between development team and business people by creating a common (UBIQUITOUS) language used by both groups

development team: UBIQUITOUS languages => code

tactical design - bottom up approach
identify events, services, entities and value object (data)

available components, technologies and other elements

potential conflicts between goals, requirements and constraints

we might use black box to delegate responsibility for the design and implementation of this building block to somebody else

the interior structure (internal building blocks and internal dependencies)

responsibility: what this black box does, its functions or service

provided interfaces: what functions, services, data this black box provide

required interfaces: what other functions, services, data this black box requires to fulfill its responsibility

additional attributes

• this black box is capable of multi user access
• what are guaranteed, minimal or average response time...

design rationale: explain the reason why it is structured in this specific way

facilitate understanding of low-level structures by showing these structures in context

can start designing and implementing system on any abstraction level and use a combination of bottom up and top down approaches during development

is approach to identify or design the building blocks of system

architecture views support both designing and communicating architectures => they are more than just a means of documentation

ultimately building blocks will be implemented in source code

if domain-related elements of system are coupled to purely technical details (like file names, specific database names...) => more difficult to understand, change or test

Trading off one attribute or quality against another might be a risk for some stakeholders => should consider and communicate such risks

functional requirements

quality requirements & quality goals

additional factors: product costs, licensing model, business model of system

externally mandated technical decisions and concepts

existing or planned hardware and software infrastructure

technological constraints on data structure and interfaces

reference architectures, libraries, components and frameworks

programming languages

organizational structure of dev team and of customer

company and team cultures

partnerships and cooperation agreements

standards, guidelines, process models (approval / release processes)

available resources (budget, time, staff)

availability, skillset, commitment of staff

local and international legal constraints

contract and liability issues

data protection and privacy laws

compliance issues or obligations to provide burden of proof

market trends

impact of further stakeholder concerns and mandated design decisions

affect several building blocks of system

to solve recurring problems (or cross-cutting concerns) - addressed within multiple elements of architecture

cross-cutting decisions can help to ensure CONSISTENCY - implement in same manner, same technology, use same patterns

Risks: if the standard is bad, systems using the standard will also be bad

Microservices (aka self-contained-systems)

architect know various architectural patterns and apply them when appropriate

patterns are a way to achieve certain qualities for given problems and requirements within their contexts

abstraction layers: lower layers hide certain details from the layers above

layers (tiers) to separate functionality or responsibility, e.g 3-tier architecture

dependencies (function or method calls) go down from upper to lower layers

strict layering: communication from one layer is restricted to the layer immediately below ti

loose layering: one layer may access all layers below it

unidirectional dependencies between layers avoid circular dependencies

simple structure, easy to understand

lower efficiency - requests from uppermost layer cross several layer boundaries until they reach the lower layers

cascade of changes when behavior of a single layer changes

Information hiding and encapsulation

Dependency inversion principle

vs SoC, SRP: a component should be responsible for a single concern. SoC is about dividing a system into components in a way that their concerns overlap as little as possible

open for extension, closed for modification

objects of a superclass shall be replaceable with objects of its subclasses without breaking the application

Clients should not be forced to depend upon interfaces that they do not use.

https://reflectoring.io/interface-segregation-principle/

Provided interfaces or Application Programming Interfaces (API)-
what is needed to USE the provided functions

Service Provider Inteface (SPI) - intended to be IMPLEMENTED or EXTENDED by another component / system

Required Interfaces - describe what a component needs to fulfill its responsibilities