Please enable JavaScript.
Coggle requires JavaScript to display documents.
Sofware Architecture Pattern - Coggle Diagram
Sofware Architecture Pattern
Layered Architecture
Open/Close Layers
Separation of concerns
De facto for most java EE application
know as n-tier pattern
Horizontal organisation
80-20 rule to minimize sinkhole anti-pattern
lends toward monolithic application
Analysis
easy to test
hard to deploy
decrease agility
decrease performance
easy to develop
difficult to scale
Even-Driven Architecture
Distributed
Asynchronous
produce highly scalable application
highly adaptable for small and large application
1 Broker topology
no central event mediator
distributed chain through message broker
ActiveMQ
HornetQ
for simple event processing
chaining of events to perform business action
events channes & event processors
Decoupled component comunicating troughout events
2 Mediator topology
needs orchestration
order that identify steps
key components
event queues
event mediator
Spring integration
Apache Camel
Mule ESB
event channels
message queues
message topics :
event processor
initial event & processing event
each event processor component should perfom a single business task
complex to implement
Analysis
increase agility
easy to deploy
hard to test
increase performance
allow fine-grained scalability
hard to develop
Microkernel Architecture
Plug-in architecture
product-based architecture
Two main components
core system
plug-in modules
provide extensibility, flexibility and isolation
modules must remain independant from one another
can be embeded in other architecture pattern
first choice for product-based application
analysis
increase agility
easy to deploy
easy to test
not scalable
hard to develop
Microservices Architecture
separatly deploybale units
increase scalability
service granularity challenge
high decoupling
disributed architecutre
REST, SOAP, JMS, AMQP, RMI
simplify SOA :
eliminate orchestration
simplify connectivity
pattern common topologies
API REST-based topology
Application REST-based topology (fat clients)
Centrelized messaging topology
avoid dependencies and orchestration
split by business functionaliy (not too fine-grained, and not too coarse-grained)
Continuous delevery and more robust
common complexity
contract creation
maintenance
governance
remote system availability
remote authenttication/authorization
Analysis
increase agility
easy to deploy
easy to test
decrease performance
increase scalability
easy to develop
Space-Based Architecture
solve scalability and concurency problems
useful in case of variable and unpredictable user volumes
referred as cloud architecture pattenr
named from tuple space (distributed shared memory)
replace central database by replicated in-memory data grid
for web application (ex : bidding applications)
main components
processing unit
virtualized middleware
messaging grid
data grid
processing grid
deployment manager
complex & expensive to implement
analysis
high agility
high ease of deployment
hard to test
increase performance
increase scalability
hard to develop