Please enable JavaScript.
Coggle requires JavaScript to display documents.
architecture monday mark richards : - Coggle Diagram
architecture monday
mark richards :
lesson 100 +
lesson 173- checklists
developer onboarding checklist
deployment checklist
code review checklist
lesson 172 - togaf
open group architecture framework
software development metodology
170 - managing code reuse in microservices
inheritance
shared libraries
a separate API
6 - classifying architectures
distributed - complexity that needs to be considered
needs contracts , maintenance, versioning, coordination
remote service availability and responsivnes -> latency because of the over the wire communication
security -> we need to authorize the caller
I didn't really like this talk, because I think we have architectural concepts that we can mix and match them (eg microservices where each microservice has 2 layered). So it's not fair to say that layered architecture is monolithic and not distributed
11 - analyzing architecture - code metrics
tools for code analysis
codecity
sonar
source mointor
jdepend ndepend
code metrics
-> as architect we are interested in trends - is our cyclometric complexity getting better or worse ?
cyclometric complexity
size of components - if over time , the component increases in size, it can be a sign of structural decay
-> number of classes per package
-> number of lines of source code (based on a context)
depth of inheritance tree (can be sign of ease of separation and modularity)
9 - analyzing architecture - macro techniques
macro detection techniques
= general structural decay indicators
static coupling ( references)
temporal coupling
component size
types of coupling
downsides of coupling
low testability
high deployment time
10 - analyzing architecture - microservices
hints of structural decay in microservices
inter-service communication -> it affects scalability, deplorability
too many orchestration requests - calling services in a certain order
to many aggregations requests - can be useful to leverage messaging
database coupling
how can we improve a system that has these cracks in the architecture? :question:
8 - analyzing architecture - components
we as architect establish the building blocks of an application = the components and the interaction between them
14 - Refactoring Patterns: Migration vs. Adaptation
migration ( a new component is created to replace the component we want to refactor)
easier to rollback changes
less overall risk
risky from keeping the functionality in both places up to date
cost - long time to implement
adaptation (refactoring the code in place - without a new component)
harder to rollback changes
no changes to calling components
15 - refactoring: business justification
e.g. split monolithic application into multiple deployable units
pros:
component decoupling will improve frequent build and deployment issuses
each part will use fever VM resources, and increase performance and allow for more growth
deployment is limited to a separate application unit, reducing deployment time and increasing robustness
why would the business care about the previous points? here's a better way to talk about this:
new functionality can be delivered faster , improving overall time to market ( because deploys are smaller and faster )
overall application quality will be improved ( smaller and faster components)
development and deployment of new functionality will be reduced (because each component is less complex and easier to understand)
relevant aspects for the business ( these have to be proven when we promise to improve them
reduce cost ( reducing bug number, actual development and testing hours; classify the type of bugs we have )
better time to market ( we can work in parallel on the services , means faster )
better user satisfaction ( count the number of bugs, the number of errors in logs)
30 - agile and software development
recommends to have the architect as scrum master (to reduce the lines of communication between roles : dev, prod owner)
responsibilities for architect when project starts:
identify characterestics
define components
select architecture patterns
diagram architecture
document decisions
architecture responsabilities after the proj started:
define components, diagram architecture, document decisions, asses architecture risk
ensure complience
analyze architecture
refactor components
17 - architecture tradeoffs
performance, scalability, extensibility, agility, maintainability, feasibility
we can't satisfy all of these at once
performance vs availability (the more available it is, the less performant it is)
why? : :question:
architecture tradeoff analysis method
has a proposed architecture
business drivers
quality attributes
think of it as defending a thesis; along with the stakeholders, conversation. produce scenarios and validate the architectue throught the scenario
results a validated and approved architecture
downsides
assumes the architecture is complet
stakeholders are often busy and distributed, hard to get in one place
assumes a one-time process with no change
assumes all scenarios are known up front
recommendation
create an architecture presentations
goal: validate the architecture and establish tradeoff ; identify and mitigate risk ; get stakeholder buy-in
cost benefit analysis method - another tradeoff analysis
business goals produce the architecture characterisitcs (perf, availability) which are considered the benefits of the architecture.
Then asses the cost of all those benefits.
recommendation to combine these
resources
software architecture in practice : addison wesley
software engineering institute digital library :
https://insights.sei.cmu.edu/library/
https://insights.sei.cmu.edu/search/#stq=cbam&stp=1
24 - lean modeling concepts
models in software architecture
business workflow model : describes the overal business process
enterprise systems model: describe the systems and their interaction
enterprise information model: phisical and logical data model, and information flow through various systems
technology infrastructure module : hardware topology, where are the virtual machines
business automation model: shows which processes are automated
because all the above models need constant updating we go a different route
Lean modeling - focus on information
create some lists
track relationship between the lists
keep these items in a repository
example of lists:
list owenership responsabilites
major business functions
applications and services
technologies and platforms
user groups and roles
standards
data stores
business segments ?
common relationship between the lists , e.g. sample query
what database and applications support which business functions?
take of applications and services, major business functions and data stores - join the tables to get the information
what technologies and standards are used by which applications?
take applications and services, standards and technologies
what user groups access which application?
application services
my conclusions: still need to keep data up to date ;
25 - architectural abstractions
5 types of abstractions for a service
location transparency - do I need to know the location of the service when invoking the service?
name transparency - when I'm invoking you , do I need to know the name of the service
implementation transparency - when I'm invoking, do I need to know which technology stack or platform you are using
access decoupling - do I need to know the protocol you;re using to accept the requests
contract decoupling - endpoint takes in (product and quantity)
architecture abstraction - we're controlling change, decoupling components
communication ways between systems - analysis on the abstraction levels
messaging e.g. rabbit mq
:check: location transparency checked - since I need to know the queue's IP but not he service which consumes the message
:check: name transparency - i know the name of the queue
:check: implementation transparency : do I know the implementation of the service? no
:red_cross: access decoupling
:red_cross: contract decoupling - need to use the same contract
adapter - a piece of code that forward the request ( service mesh, an intermediary)
:check: location transparency
:check: name transparency
:check: implementation transparency
:check: access decoupling - the adapter can change the protocol when calling the second service
:check: contract decoupling - the adapter can extend the contract
REST
:question: location transparency; going point to poing - no. If using an api layer, or revers proxy or DNS - it can be location transparency
:check: name transparency - the argument here is that you can decouple routing from the controller method
:check: implementation transparency
:red_cross: access decoupling
:red_cross: contract decoupling
