Technology and patterns

Create Application Overview

Determine application type
- Bot? Console? Service? Web? Desktop? Maybe Serverless?
Identify deployment constraints
- Where are you going do deploy the application?
Identify architecture pattern
- Layered? Component? Microservices?
Determine technologies
- What technologies are available? Libraries? Third-party tools?
- A lot of factors play here… Choose wisely!
Create your first diagram

Application Types

Web application
- Best suited for:
  - User interface
  - User initiated actions
  - Large scale
  - Short, focused actions
- Request-Response based

Web application

Web API
- Best suited for:
  - Data retrieval and storage
  - Client initiated actions
  - Large scale
  - Short, focused actions
- Usually REST based
- Returns data, not HTML

Web api

Mobile Application
- Best suited for:
  - Well, mobile devices
  - User interaction (games, social apps)
  - Front end for Web API
  - Location & camera-based systems
- Usually work with a Web API

Mobile application

Desktop Application
- Best suited for:
  - User centric actions
  - Gaming
- Has all its resources on the local PC
- Might connect to the web
- Great UI

Desktop Application

Console Application
- Best suited for:
  - Long-running processes
  - Short actions by trained power-users
- No fancy UI
- Require technical knowledge
- Limited interaction
- Long or short-running Processes

Console Application

Service
- Best suited for:
  - Long-running processes
- No UI at all
- Managed by the OS service manager

Service

Selecting technology stack

This is a super important decision (especially if you are a consultant)
- Mostly because it is almost irreversible
- And developers get emotional to their favorite tools
The decision must be:
- Made with a clear mind, heavily documented and based on a group effort
Main considerations besides performing the task:
- Community – check Stack Overflow
- Popularity – check Google Trends
- Current developer skills – unknown technologies produce delay and low quality
- Deadline – advanced technologies take more time
- Support – developers should develop, be careful with shiny new tools
- Products – use external and existing tools but always estimate the cost

General tips and tricks

Do not choose on recommendation
- Or marketing tricks from vendors
Always do a CBA and ROI (or at least a pros/cons list)
- Which type system – static or dynamic?
- What is our infrastructure?
- Is the community using the tool?
- Is performance critical?
- Do we need to analyze the learning curve?
- Can you easily hire a new team member?
Stay rational and don’t argue with your colleagues!
- Use the right tool for the job!
- And not vice-versa!

Popular technologies

Web applications – back-end
- Mature - .NET, Java, PHP
- Newer - Node.js, Python, .NET Core, Go
- Serverless – Amazon Lambda, Azure Functions
Web applications – front-end
- HTML, CSS & JavaScript (or maybe Web Assembly, if you are adventurous)
- Which JavaScript framework? Angular? React? Vue? Svelte?
Mobile applications
- Native? Hybrid? Cross-Platform?
- The battle is development time versus capabilities
Desktop applications
- WinForms, WPF, UWP

Database technologies

Key-value
- Useful for cache, publish/subscribe, leaderboards
- Not your primary database
- Redis, Memcached
Wide column
- Each key has multiple columns without a schema
- Cannot do joins and scales easily
- Useful for time-series (IoT), historical records, high-write/low-read scenarios
- Not your primary database
- Cassandra, HBase
Document
- Each document is a container for key-value pairs
- Fields can be indexed
- Columns can be collection – query relational data without joins
- Reading data is usually super fast, but writing data tends to be more complex
- General purpose – applications, games, IoT, content-management
- If you have unstructured data – a document database is a great start
- No standard language for queries
- Not suitable for huge graphs of data – social networks, for example
- MongoDB, Firestore, DynamoDB, CouchDB
Relational
- Tables are connected through relationships
- Requires a schema
- ACID compliant – atomicity, consistency, isolation, durability
- Good for stable data
- More difficult to scale
- Supports SQL – a query language
- General purpose - perfect for most applications which does not have unstructured data
- Some databases support JSON columns
- MySQL, PostgreSQL, SQL Server
- Modern databases like CockroachDB – designed for scale
Graph
- Data is represented as nodes
- Relationships between the nodes are edges
- Instead of many-to-many tables, you have direct connections
- Languages like SQL
- Better performance than relational databases when datasets are large
- Useful for – recommendation engines and well… graphs
- Neo4j, CosmosDB
Search engine
- Full-text search engine
- Like document databases but under the hood all the text is indexed
- Works like an index at the back of a book
- Can easily rank results
- Useful for search engines and typeahead scenarios
- Elasticsearch, Algolia, MeiliSearch
Multi-model
- You do not think about data modeling, schemas, shards, replications
- You describe how you want to use the data with GraphQL
- It chooses the database type behind the scenes
- ACID compliant, extremely fast and you do not care about provisioning infrastructure
- Useful for… everything?
  - But is it mature enough?
- FaunaDB

Cloud Technology

Other Important Technologies

Web servers: Nginx & Apache
Containers & orchestrators: Docker & Kubernetes
Message brokers: RabbitMQ & Kafka
Logging
- ELK Stack – Elasticsearch, Logstash, Kibana
CDN

Identify Key Issues

Quality attributes:
- System, run-time, design, user
- Performance, stability, manageability, configurability, etc.
System wide concerns:
- Authentication & authorization
- Caching
- Communication
- Configuration management
- Logging & exception management
- Validation

Create Candidate Solution

Create a Baseline architecture
Create a Candidate architecture
Develop Architectural Spikes
- Proof of concept projects to validate unknown concepts
Create Activity, Sequence, State, and Component Diagrams
Create Class Diagram if needed
- They are too low-level
- Document only the most important classes
- Everything else should be done by the Lead Developer

During Each Cycle

Do not introduce new risk
- Do not introduce untested technologies and concepts
Mitigate more risk than baseline
- Each cycle should reduce the risk
Meet additional requirements
- Cover more and more requirements until you meet them all
Enable more key scenarios
Address more key issues
Start communicating architecture when you exceed 50% coverage
- If you have the feeling you are half done, invite the developers
- You don’t want to be the bottleneck

Architecture design patterns

Client/Server Pattern
- Distinct client and server
- Separated by network
- Communication protocol
- Many clients, one server
- Pros:
  - Secure & Simple
  - Centralized Control
  - Easy to manage
- Cons:
  - Requires network, difficult to scale
  - Single point of failure
Layered Pattern
- Strict areas of concern
- Layers may only communicate with peers above/below
- Pros:
  - High abstraction & High isolation
  - Structured communication
  - Easy to scale out
- Cons:
  - Deep call chains
  - Can hide complexity
  - May harm performance
  - Lowest layer must cover all use cases
N-Tier Pattern
- Layers deployed to servers
- Usually - 3 tiers, always start with them
- Communication between layers uses network
- Pros:
  - High abstraction & High isolation
  - Structured communication
  - Easy to scale out
- Cons:
  - Network = point of failure
  - Network may be slow
  - Coarse interfaces
  - Hard to debug
Component-based Pattern
- Components are modular building blocks of software
- Grouped into areas of concern
- Clearly described interfaces
- Containers provide additional services
- Pros:
  - Easy deployment & Allows 3rd party tools
  - Promotes modularity & Few unanticipated interactions
- Cons:
  - Coarse building blocks & Can be expensive
  - Initialization may be slow & Harder to develop & maintain
Object-Oriented Pattern
- Uses classes
- Grouped into areas of concern
- Describes public members
- Uses inheritance, composition, aggregation, and associations
- Pros:
  - Easy to understand & Promotes reuse
  - Easy to test & debug & Highly cohesive
- Cons:
  - Inheritance hard to get right & Useful only if you do not have a Lead Developer
  - Many unanticipated communications & Too detailed
MVC Pattern
- Designed for presentation layers
- View handles output
- Model handles data
- Controller handles interaction
- Pros:
  - Strict separation of concerns
  - Scales well
- Cons:
  - High overhead
  - Scattered code
  - Hard to data-bind
MVVM Pattern
- Derived from MVC pattern
- View handles output
- Model handles data
- View Model is binding source
- Pros:
  - Strict separation of concerns & Scales well
  - Easy to data-bind
- Cons:
  - High overhead
  - Scattered code
  - Controller not separated
Service-Oriented Pattern
- Discrete business services
- Use network to communicate - HTTP, XML, SOAP, Binary…
- Pros:
  - Business domain alignment & High abstraction
  - Discoverable, resilient, Allows 3rd party libraries & Cross-platform
- Cons:
  - Clients must handle slow, offline network
  - Coarse interfaces
  - May harm performance
  - Security issues
Microservice Pattern
- Services calling services
- Can use fast private network and RPC
- Deployed on multiple servers
- Pros:
  - Modular & Reduced abstraction
  - Discoverable, resilient & Less coarse interfaces
  - Can use fast network
- Cons:
  - Must cope with slow, offline network
  - More unanticipated communications
  - Hard to do transactions & Hard to test, debug, deploy
Message Bus Pattern
- Services connected to shared data bus
- Uses messages for communication
- Supports discovery, failover
- Pros:
  - Easy to extend & Simple communication
  - Very flexible & Easy to scale
  - Easy discovery, failover
- Cons:
  - Bus = single point of failure
  - Coarse communications
  - Can be slow & Hard to test, debug