Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software Deign & Architecture, Microservices The Big Picture - Coggle…
Software Deign & Architecture
Architectural Patterns:
Wide-structural properties,
Impact architectural of subsystems.
It is a
way to implement an Architectural Style
It focuses
to solve the application architectural problems.
Introduction
Patterns may be represented using tabular and graphical
descriptions.
Patterns are a means of representing, sharing and
reusing knowledge.
An architectural pattern is a stylized description of good design practice, which has been tried and tested in different environments.
Patterns should include information about when they are
and when the are not useful.
Pipe and filter Architecture
Advantages
Can be implemented as
either a sequential or concurrent system.
Evolution by
adding transformations is straightforward.
Easy to understand and supports transformation reuse
Workflow style
matches the structure of many business processes.
Disadvantages
The format for data transfer has to be agreed upon between
communicating transformations.
Each transformation must parse its
input and unparse its output to the agreed form.
This increases system overhead and may mean that it is impossible to reuse functional transformations that use incompatible data structures.
When used
Commonly used in data processing applications (both batch- and transaction-based) where inputs are processed in separate stages to generate related outputs.
Introduction
The data flows (as in a pipe) from one component
to another for processing.
The processing of the data in a system is organized so that each processing component (filter) is discrete and carries out one type of data transformation.
Layered Architecture
Advantages
Allows replacement of entire layers so long as the interface is maintained.
Redundant facilities (e.g., authentication) can be provided in each layer to increase the dependability of the system.
Disadvantage
Performance can be a problem because of multiple levels of interpretation of a service request as it is processed at each layer
In practice, providing a clean separation between layers is often difficult and a high-level layer may have to interact directly with lower-level layers rather than through the layer immediately below it.
When used
Used when building new facilities on top of existing systems;
when there is a requirement for multi-level security
when the development is spread across several teams with each team responsibility for a layer of functionality;
Introduction
However, often artificial to structure systems in this way.
Organises the system into a set of layers (or abstract
machines) each of which provide a set of services.
Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected.
Used to model the interfacing of sub-systems.
MVC Pattern
Disadvantages
Can involve additional code and code complexity when the data model and interactions are simple.
Introduction
The Model component manages the system data and associated operations on that data.
The system is structured into three logical components that interact with each other
The View component defines and manages how the data is presented to the user.
The Controller component manages user interaction (e.g., key presses, mouse clicks, etc.) and passes these interactions to the View and the Model. See Figure 6.3.
Separates presentation and interaction from the system data
Advantages
Supports presentation of the same data in different ways with changes made in one representation shown in all of them.
Allows the data to change independently of its representation and vice versa.
When used
Used when there are multiple ways to view and interact with data.
Also used when the future requirements for interaction and presentation of data are unknown
Repositoty Architecture
Disadvantages
The repository is a single point of failure so problems in the
repository affect the whole system. May be inefficiencies in
organizing all communication through the repository
Distributing the repository across several computers may be
difficult.
When used
You should use this pattern when you have a system in which large volumes of information are generated that has to be stored for a long time
You may also use it in data-driven systems where the inclusion of data in the repository triggers an action or tool.
Introduction
All data in a system is managed in a central repository that is
accessible to all system components.
Components do not
interact directly, only through the repository.
Advantages
Components can be independent—they do not need to know
of the existence of other components. Changes made by one
component can be propagated to all components
Changes made by one component can be propagated to all components. All data can be managed consistently (e.g., backups done at the same time) as it is all in one place.
Client-server Architecture
Advantages
General functionality (e.g., a printing service) can be available to all clients and does not need to be implemented by all services.
The principal advantage of this model is that servers can be
distributed across a network.
Disadvantages
Performance may be unpredictable
because it depends on the network as well as the system.
Each service is a single point of failure so susceptible to denial of
service attacks or server failure
May be management problems if servers are owned by different organizations.
When used
Used when data in a shared database has to be accessed from a
range of locations.
Because servers can be replicated, may also be
used when the load on a system is variable.
Introduction
In a client–server architecture, the functionality of the system is organized into services, with each service delivered from a separate server
Clients are users of these services and access servers to make use of them.
Design Principles
It provide
high level guidelines
to design better software applications
Principles apply to all of programming
Core Design Principles
https://www.youtube.com/watch?v=llGgO74uXMI
:check:
SOLID Principle
Single Responsibility Principle
A class should have one, and only one, reason to change.
Long methods
issues
testing
reading
duplication
debug
optimization
low cohesion
high coupling
tips
delete own code
SLAP
Compose Method Pattern
self explanatory
comment
WHY
refactor code
Single Level of Abstraction Principle
Opened Closed Principle
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification
Open for Extension
Close for Modification
Liskov’s Substitution Principle
Derived or child classes must be substitutable for their base or parent classes
Interface Segregation Principle
Don't force any client to implement an interface which is irrelevant to them
Dependency Inversion Principle
High-level modules/classes should not depend on low-level modules/classes. Both should depend upon abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions.
Complexity
COHESION
coupling
transform
tight
transform
depending on class
loose
depending on interface
remove
tight
cyclic
connectivity
inheritance
specific
effective
separation
narrow
YAGNI
You Are Not Gonna Need It
postpone
research
find value
inherent
HIDE
accidental
ELLIMINATE
Steps
un-emotional
solve problem
ignore solution
let go of ego
updating
improvement
folowing instructions
not following
following to much
review code
Definition
re-writable
iteration
update
evolve
adaptability
changeability
Don't Repeat Yourself
(DRY)
don't duplicate
effort
multi-site change
GUI
xml
database
code
tools
simian
CPD
Don't Repeat Yourself
Keep it simple, stupid (KISS)
familiarity
Keep It Simple
focus
solve problem we know about
understandability
less fails
no distractions
Architectural Styles
Shared memory
Rule-based
Blackboard
Data-centric
Adaptive systems
Plug-ins
Microkernel
Domain specific languages
Reflection
Structure
Layered
Component-based
Monolithic application
Pipes and filters
Distributed systems
Peer-to-peer
Cloud computing patterns
Service-oriented
Object request broker
Shared nothing architecture
Client-server (2-tier, 3-tier, n-tier exhibit this style)
Space-based architecture
Representational state transfer (REST)
Messaging
Event-driven (implicit invocation)
Channels
Consumers (Sinks)
Emitters (Agents)
Publish-subscribe
More Dynamic Network Topology
Decreased flexibility of publisher and structure of the data
Greater Scalability
Asynchronous messaging
Message-oriented middleware (MOM)
API
allows application modules to be distributed over heterogeneous platforms
Middleware distributed communication layer
sending and receiving messages between distributed systems.
governs runtime interaction of flow control and data transfer
contains a set of rules, constraints, and patterns of how to structure a system into a set of elements and connectors
How to decide architecture style?
Depends on how quality attributes
Each architecture style has its advantages, disadvantages, and potential risks
Three categories
Business attributes
Implementation attributes
Runtime attributes
Why Architecture Style?
Saves cost and time on design!
Architecture style represents
Once overall structure determined, rest are easy
abstracts the common properties of a family of similar designs.
Key components
Elements
that perform functions required by a system
Constraints
that define how elements are integrated to form the system
Attributes
that describe the advantages and disadvantages of the chosen structure
Connectors
that enable communication, coordination, and cooperation among elements
Design Patterns
Medium-scale (finger-grained) set of object-oriented detailed design solutions
Strong influence on
subsystems architectural
, not on the fundamental structure
It is a way to solve a localised problem
It is used
to solve the technical problem in application development.
Deep-Dive: Design Patterns
Classification
Creational Patterns
Builder
Examples in .NET:
StringBuilder class
???
Factory method
Examples in .NET:
Convert class
Parse()/TryParse() methods
???
Singleton
Addressing issues
How can the number of instances of a class be restricted?
How can be ensured that a class has only one instance?
How can a class control its instantiation?
How can the sole instance of a class be accessed easily?
Differences with static class
Singleton object stores in Heap but, static object stores in stack
You can clone the object of Singleton but, you can not clone the static class object
In c# a static class cannot implement an interface. When a single instance class needs to implement an interface for some business reason or IoC purposes, you can use the Singleton pattern without a static class.
A singleton can be initialized lazily or asynchronously while a static class is generally initialized when it is first loaded
Solution
A singleton implementation may use lazy initialization, where the instance is created when the static method is first invoked.
Hide the constructor of the class.
Define a public static operation (getInstance()) that returns the sole instance of the class.
Implementation - double check when locking to prevent race conditions in parallel access from multiple threads.
Mentioned by GoF and CleanCode
Ensure a class has only one instance.
Sources
Wikipedia
Creational Design Patterns
on Csharp Star
Singleton Design Pattern in C#
on Csharp Star
Common uses
The abstract factory, builder, and prototype patterns can use Singletons in their implementation.
State objects are often singletons.
Logger, cache, etc.
Facade objects are often singletons because only one Facade object is required.
Singletons are often preferred to global variables
Provide a global point of access to it.
Multiton
???
Abstract factory
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
Addressing issues
How can an application be independent of how its objects are created?
How can a class be independent of how the objects it requires are created?
How can families of related or dependent objects be created?
Pros
The intent in employing the pattern is to insulate the creation of objects from their usage and to create families of related objects without having to depend on their concrete classes.
This allows for new derived types to be introduced with no change to the code that uses the base class.
Use of this pattern makes it possible to interchange concrete implementations without changing the code that uses them.
Mentioned by GoF and CleanCode
Solution
A class delegates object creation to a factory object instead of creating objects directly.
Encapsulate object creation in a separate (factory) object.
That is, define an interface (AbstractFactory) for creating objects, and implement the interface.
Articles
Creational Design Patterns
on Csharp Star
Fabryka abstrakcyjna(abstract factory) i jej rodzaje by DevMan Blog
Wikipedia
Object pool
???
Dependency Injection
???
RAII
Resource acquisition is initialization
???
Lazy initialization
???
Prototype
???
Structural patterns
Decorator
Articles
Decorator by DevOnBoard Blog
???
Examples in .NET:
Stream class and its derivatives
(all streams in .NET provide the same basic functionality, however each stream functions differently)
Module
Adapter / Wrapper / Translator
???
Examples in .NET:
Runtime Callable Wrappers - RCW
(adapters that let .NET managed code easily
call into legacy COM code via a .NET API)
Marker
Bridge
Proxy
Flyweight
Extension object
Facade
Composite
Front controller
Twin
Behavioral patterns
Blackboard
Null object
Observer or Publish/subscribe
???
Examples in .NET:
events / delegates
IObservable<out T>, IObserver<in T> interfaces
Articles
Obserwator by DevOnBoard Blog
Specification
State
Memento
Mediator
Strategy
Iterator
Examples in .NET:
IEnumerable interface, foreach, yield
???
Chain of responsibility
Interpreter
Template method
Servant
Command
Visitor
Concurrency patterns
Monitor object
MDP
Messaging design pattern
Thread-specific storage
Event-based asynchronous
Active Object
Double-checked locking
Guarded suspension
Binding properties
Blockchain
Join
Reactor
Read-write lock
Thread pool
Balking
Lock
Scheduler
Other
Page object
Sources
Books
Design Patterns
by Gang of Four
Code Complete
by Steve McConnell
Articles
What design patterns are used throughout the .NET Framework?
Architectural pattern
on Wikipedia
Creational Design Patterns
on Csharp Star
Software design pattern
on Wikipedia
Microservices The Big Picture
What Are Microservices?
Software Development Lifecycle
Agile Development
Plan & design
Test
Release
Monitor
Mentain
Requirements
Develop
What Are Microservices?
Set of practices
Increase speed
Scale
Technology Agnostic
Principles and architectural patterns
MicroService
Micro
Identify sub-domains
Do one thing and it right
Scope of functionalities
Service
Service-oriented architecture (SOA)
Independently deployable component
Interoperability
Message based communication
The microservice architetural stylke is an approach to developing a single application as a suite of small services, each running in its own process and communication with lightweight mechanisms.
Microservices are small, autonomus services that work together.
Microservices Elements
Security
Scalability and Availability
Monitoring
Deployment
Revising The Microservices
Scalability and Availability
Availability
Single Point of Failure: :check:
Gateway, Broker, Registry, IAM
:check: - We need to scale those Horizontaly to have multiple instances and clustered to keep in sync
Vertical - More resources (CPU & RAM)
Horizontal - More machines:
Service registry - Load Banalcer (Round-robin, weight, capacity)
Load-Balancing Tools: :check:
Ribbon
Meraki
Security
Access Token:
Store Info about the user
Exchanged between services
JSON Web Token
Cookie
Identity and Access Management
Single Sign-on : Kerberos, OpenID, OAuth 2.0, SAML :check:
Identity access management systems: Okta, Keycloak, Shiro :check:
Authentication And Authorization
Authentication - someone is who he claims to be
Authorization - refers to rules that determine who is allowed to do what
Data Store
User Interface
Data Store
Data Synchronization
No distributed transaction
Immediately consistent
Eventual consistency
Patterns
:
Capture data change
Event sourcing
: for a period of time, same product may have different price or description on both subdomains
Publishing Events :check:
AKA
Kafca
RabbitMQ
Capture DataChange: :check:
Debezium
Independent
Different requirements
Relational
NoSQL
User Interface
UI Composition
Server Side
Client side
Independent teams
own set of components
unique UI
single application
Building Microservices
Subdomain
Order
Product
User
Dependencies for these 3 subdomains
Domain Driven Design
gives us techniques and patterns to solve the dependencies
Sharing database is discouraged and is an antypattern
Duplicate entities that depend on eachother
They should be Independent
Domain
Services
Distrbuted Services
Services
RPC - Remote Procedure Invocation
Request / Reply principle
Can be:
Synchronus
Asynchronus
Technologies: :check:
-REST, SOAP, gRPC
APIs and Contracts
SOAP, REST, gRPC
You have yo describe your microservice api using: :check:
WSDL, Swagger, IDL (Interface Definition Language)
Messaging
Message or event
Broker or channel
Publish
Subscribe
Asynchronuous messaging keeps things Loosely coupled
Technologies for Message Brokers: :check:
Kafka
RabbitMQ
Protocol Format Exchange
Text : XML, JSON, YAML
Binary: gRPC
Distributed Services
Cross-origin Resource Sharing (CORS)
Same-Origin policy documents can communicate with the documents on the same domain, same protocol, server, port
HTTP Restricts cross-origin :check:
Microservices use different HTTP headers to allow them to communicate cross-origin
Access-Control-Allow-Origin Headers
Service Registry
is the phonebook for the Microservices
Microservices register their location on startup
Famous Service Registries: :check:
Eureka
zookeeper
Consul
Gateway
access individual services
Single entry point
Unified interface
Cross-cutting concerns
API translation
Technologies: :check:
Zuul
Netty
Finagle
Pattern:
:check:
Circuit Breaker
Service Available
Network Failure
Heavy load
Domino Effect
Invoke via proxy
Deviate calls
reintroduce traffic
Technologies for Circuit Breaker: :check:
Hystrix
JRugged
Building a Monolith
Pro / Cons
Cons
New team members productivity
Growing Teams
Code harder to understand
No emerging technologies
Scale for bad reasons
Huge database
Pro
Simple to develop
simple to build
simple to test
simple to deploy
Simple to scale
Model
User Interface
Single database
Expose APIs
Multiple instances / Load balancer
Organization
Team per subdomain
right-sized teams
independent
responsible
agile and devops
communication
Management
Code
Documentation
Repository
Introduction
Microservice terminology
Designing
Data Store
Temote communication
Monitoring
Courses
Dino Esposito: Modern Software Architecture
Rang Dhiman : Microservices Architecture
Are Microservices Right for Your Organization?
