Fundamentals and essentials

Software architecture

• Structured solution to address all common software attributes:

  • Meets all the requirements
  • Performance optimized
  • Security in check
  • Manageability for developers
  • Scalability for business growth
  • Accessibility for easier user experience

• Major requirements:

  • User requirements – the way end-users interact with the system
  • Business requirements – cheaper, faster, better than competitors
  • IT system requirements – infrastructure requirements

What composes an architecture?

• The structural elements and interfaces composing the system

  • Objects – the low-level building blocks of the system

• How these elements behave in collaboration

  • How communication is done in the architecture

The composition of elements into larger subsystems * How the elements are mapped to trees or graphs – the high-level data structure

The architectural style that guides this composition

What composes an architecture?

• Additionally, our design should cover:

  • Functionality
  • Usability
  • Resilience
  • Performance
  • Economic and technology constraints
  • Trade-offs and aesthetic concerns

• The goal is to:

  • Document high-level structure
  • Do not go into implementation details
  • Minimize complexity
  • Address all requirements
  • Be compatible with all use cases and scenarios

Our architecture needs

• Separation of Concerns
• Encapsulation
• Dependency Inversion
• Explicit Components
• Single Responsibility
• Don’t Repeat Yourself 
• Persistence & Infrastructure Ignorance
• Presentation Ignorance
• Bounded Contexts
• Testability

Architecture abstraction

• Layers:

  • System, Sub-systems, Layers, Components, Classes, Data and Methods

• Bad Architecture:

  • Complex, Incoherent, Brittle, Untestable, Unmaintainable

• Good Architecture:

  • Simple, Understandable, Flexible, Testable, Maintainable

Software Architecture Design Tips

• Build to change instead of building to last

  • You are going to change your solution multiple times
  • Create around modularity and flexibility

• Use models, but only to analyze and reduce risk

  • The models should be more abstract, otherwise you are taking the role of a developer

• Use visualizations to communicate and collaborate

  • Your architecture is going to be a large diagram

• Identify and research critical points of failure

  • Put in work in research in everything advanced
  • Security, scalability, resiliency

Areas Of Software Architectures

• The goal of a software architect is to minimize complexity
• This can be accomplished by separating the design into different areas of concern
• Also known as modules (or components)

Key Principles Of Software Architectures

• Separation of concerns

  • Each object and module should be in its own concern and context

• Single responsibility principle

  • Elements in our design must have a single purpose

• Principle of least knowledge

  • Components do not know about the internals of other components
  • Done through interfaces

• Don’t repeat yourself

  • Don’t have multiple components with the same purpose

• Minimize upfront design

  • Try to design the minimum architecture so that developers can work
  • You will polish the next sections later

General Guidelines

• Use consistent patterns in each layer

  • If you decide to use MVC pattern in the presentation layer – stick to it
  • If you use CQRS in the application layer – stick to it

• Do not duplicate functionality

  • Do not have a caching component in all layers

• Prefer composition over inheritance

  • It is complicated to create huge hierarchies
  • Work with the Lead Developer here

• Establish a code convention

  • Define the code style and preferably automate it
  • Work with the Lead Developer here

Layer Guidelines

• Separate areas of concern

  • Each layer should have one role only

• Define communication between layers

  • How does the presentation layer communicate with the business layer?

• Use abstraction to loosely couple layers

  • Use interfaces for every communication
  • Objects should not be tight to a particular platform or technology

• Don’t mix different types of components in a layer

• Use a consistent data format within a layer

Component Guidelines

• No component should rely on the internals of another

  • Components should be black boxes

• Do not mix roles in a single components

  • Web controllers should not have business logic
  • Business layer should not have HTTP concerns

• Define clear contracts for components

  • All public methods and properties should be scoped in advance

• Abstract system wide components away from other layers

  • As soon you have a component which is accessible in multiple layers
  • Put it in a system-wide area of concern

Unified Modelling language

• From Wikipedia: A general-purpose, developmental, modeling language that is intended to provide a standard way to visualize the design of a system

• Main attributes:

  • Visual – it is easy to see the representation of the architecture
  • Abstract – it stays away from implementation details
  • Descriptive – shows the complete representation
  • Standard – UML is the world standard
  • Supports Code Generation – specific sections can be converted to code
  • Supports Reverse Engineering – create UML from code

• You should know it in case the client wants it

  • But can easily avoid it

UML design elements

• Models

  • Container for the design
  • Are you looking at the entire system? A subsystem? A feature?

• Views

  • A way to look at the system
  • Is it an external view? Or the internal structure?

• Diagrams

  • Specific drawings that illustrate the architecture

UML Model Types

• Business System Model

  • Non-technical model
  • External View
    • Looking at the system as a black box
  • Internal View
    • A lot more details

• IT System Model

  • Specifically looks at technology
  • Static View (Structure View)
    • How the different elements fit together
  • Dynamic View (Behavioral View)
    • How these elements call each other

UML Diagram Types

• Component Diagram
• Class Diagram
• Sequence Diagram
• State Diagram
• Activity Diagram
• Layer Diagram
• Use Case Diagram
• There are others…

The Component Diagram

• Shows components

  • Modular building blocks

• Shows implemented and required interfaces

• Components can be nested

• If you decide to describe your architecture with a component diagram, you will have a very descriptive image

The Class Diagram

• Shows classes
• Shows methods and fields
• Shows associations, generalizations and cardinality
• Quite detailed in terms of implementation
• The Lead Developer should do this

The Sequence Diagram

• Shows call sequence
• Shows calling class, called method and return data type
• Can depict loops

The State Diagram

• Shows states or activities
• Shows allowed transitions
• Can be nested
• Can depict internal activities

The Activity Diagram

• Shows process or workflow
  • Like the famous flow charts
• Can be nested
• Can show concurrent actions
• Can have swim lanes

The Layer Diagram

• Non-standard, invented by MS
• Shows areas of concern
• Shows references between areas
• Can be validated

The Use Case Diagram

• Shows actors
• Shows use cases
• Binds actors to use cases
• Can depict generalizations

UML Diagrams In Architectures

• UML as Sketch
  • Intended for brainstorming and general loose guidelines
• UML as Blueprint
  • Very detailed, you can write code based on the diagrams
  • Forward Engineering - use diagram to generate code
  • Reverse Engineering - build diagram from existing code
• UML as Validation
• Validate implementation against diagram

The Process For Designing Architectures

Create Or Adjust Objectives

• Identify scope of architecture
  • What are the high-level objectives and requirements?
  • New technologies? Server? Client? Proof of concept?
• Estimate time to spend
  • Do you have months? Do you have weeks?
• Identify audience
  • CEO? Developers? Functional Analyst?
• Identify technical, usage and deployment constraints
  • What are the available technologies?
  • How many people use the system simultaneously?
  • How many servers do you have? Cloud? On premise?
  • These requirements are super important!

Identify Key Scenarios

• Key scenarios:

  • Significant unknown/risk – promo codes on scale
  • Significant use case – payments integration
  • Intersection of quality/function – clashing of these two attributes
  • Tradeoff between attributes – consider the trade offs

• Significant use cases:

  • Business-critical – part of the core business domain
  • High impact – very important for the end-users

• Create Use Case Diagrams

Two types of requirements

• Functional

  • Business flows
  • What the user should do
  • User interfaces
  • And many more…

• Non-functional

  • Performance
  • Load
  • Data volume
  • Concurrent users
  • SLA
  • These are the most common ones

Performance requirements

• “What is the required performance of the system?”
  • “SUPER FAST!”
• Always talk in numbers!
  • For example, if you have an end user – each task should complete in less than a second!
• Think about latency
  • How much time does it take to perform a single task?
  • How much time will it take to store a user in the database?
• Think about throughput
  • How many tasks can be performed for a given time unit?
  • How many users can be saved in the database in a minute?

Performance numbers Example

• Let’s say we have a task
  • Storing a user in database
• And its latency is 1 second
  • This is quite slow, but it is just a demonstrational number
• What is the throughput for 1 minute then?
  • In a well-designed system – more than 1000 users
  • In a badly designed system – around 60 users
• Both attributes are important!

Load requirements

• Load is quantity of work without crashing
  • In a Web API – how many concurrent requests could the server handle without crashing
• Difference with throughput:
  • Throughput – 100 requests/second
  • Load – 500 requests without crashing
• Users can tolerate a bit slow system
  • But they hate crashing ones!
• Best practice is to always plan for the most extreme cases!
  • For example – Black Friday in an e-commerce site!

Data volume requirements

• How much data the system will accumulate over time
• This requirement dictates:
  • The database type
  • Designing queries in the database
  • Storage planning
• Two aspects:
  • Data required on “day one”
    • For example – initially we need 1 GB of data
• Data growth
  • For example – our database grows annually with 2 TB of data

Concurrent users requirements

• How many users will use the system simultaneously
• It is different than the load requirements
  • Concurrent users have “dead times”
  • They read the page, watch something on it, but do not make requests
  • Load requirements consider the actual requests
• The rule of thumb is to take the load requirements
  • And multiple them by 10!
  • But this depends on the system type

Service Level Agreement requirements

• What is the required uptime for the system in percentage
  • For example, 99.99% uptime
  • This is translated to ~1 hour of downtime in a year
  • It would be quite impressive!
• It is the solution’s architect to manage the clients’ expectations
  • If the expected uptime is 99.999%
  • Just tell them that we will need at least five different data centers
    • On independent continents
    • With variety of power supplies
    • And multiple Internet providers
• This answer usually brings them down to Earth?

Who defines these requirements?

• The Functional Analysts and the CEO usually provide a well documented business and functional requirements of the system
• But who defines the non-functional ones?
  • It is the Solution’s Architect job to frame them
    • By starting discussions
    • And asking the right questions
    • And keeping the expectations realistic and meaningful
    • There is no need to fight for every millisecond
    • The users will not notice that
• Never design a system without the non-functional requirements!