Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Architecture Patterns

No description
by

Lenin Lozano

on 20 April 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Architecture Patterns

Architecture Patterns
Lenin David Lozano
Consultor en Arquitectura
2017

Patrones Arquitectónicos
También llamados Estilos Arquitectónicos
Es una solución a un problema en un contexto
Un sistema BIEN ESTRUCTURADO está lleno de patrones
Catalogo de Patrones
Separación de Intereses
Asignación de Responsabilidades
Anatomía....
Hexagonal/Clean Architecture
How It look?
Que pasó con la arquitectura por capas?
Mala implementación ....
Dependencias y acoplamiento
Remote Procedure Calling Architecture
Event Driven Architectures
Entidades
Reglas de negocio de alto nivel y generales.
No solo aplican al sistema sino a la organización.
Componentes reutilizables en la empresa.
Casos de Uso
Reglas de negocio especificas a la aplicación
Aqui se encapsulan los casos de uso analizados.
Adaptadores
Puertos y abstracción a la infraestructura externa.
Herramientas Externas - Infraestructura
Patrón Adapter - Plugin - Gateway
Transformar al lenguaje que se habla en los casos de uso
Inversión de Control - Inyección de Dependencias
"Don't call me, I call you"
1. High-level modules should not depend on low-level modules. Both should depend on abstractions.

2. Abstractions should not depend on details. Details should depend on abstractions.
Comunicación Interprocesos (IPC)
Permitir que los programas realicen llamadas a funciones localizadas en otras máquinas.
Dependen de la red subyacente
Definición de un protocolo
Tipos de Comunicación
Request-Response
Fire and Forget
Persistente
Transitoria
Explicita
Implícita
Bidireccional
Unidireccional
Modelos de Comunicación
RPC
RMI
MOM
Stream
Multicast
Árbol de Invocación Remota
Binaria
Texto
SOAP
REST
XML sobre HTTP
Web Services
CORBA
RMI
DCOM/COM+
Minimizan el acoplamiento entre las partes
Evento??
Una "cosa notable" que ocurre dentro o fuera de tu negocio.
Estilos de Procesamiento
Simple
Flujo
Complejo
Structure
http://www-01.ibm.com/support/knowledgecenter/SSGMCP_4.2.0/com.ibm.cics.ts.eventprocessing.doc/concepts/dfhep_definition.html
An architectural Pattern expresses a
fundamental structural organization schema
for software systems. It provides a set of
predefined subsystems, their responsibilities,
and includes rules and guidelines for
organizing the relationships between them

...vs Design Pattern
CODE vs STRUCTURE
Where can I find patterns?
From mud to structure
Distributed Systems
Interactive Systems
Adaptable Systems
Layered Architecture
Interés principal....
Mantenibilidad
Large Systems
Each layer…
… is client of the lower layer
… provides services to the upper layer
Helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction.
Inconvenientes
Acoplamiento de logica de negocio con elementos externos
Preocupación por detalles y no por la arquitectura

Improving Layered Architecture/
Diference.....
Business/Domain centered
Pipes and Filters
Structure for systems that process a stream of data
It divides the tasks of a system into
several processing steps (filters)
These steps are connected by the
data flow (pipes)
Elements
Pipes
Filters
ETL (Extract, Transform, Load)
Model View Presenter
More suitable for Web
MVC start with SmallTalk and only works for SmallTalk
MicroKernel Architecture
MicroServices Architecture
Model View ViewModel
Broker Pattern
Decoupled components that interact by remote service invocations
Broker:
Responsible for coordinating communication, such as forwarding requests, as well as for transmitting results and exceptions.
Your environment is a distributed and possibly heterogeneous system with independent cooperating components.
Think about it
inter-process communication is required
dependency on the communication mechanism used
clients need to know the location of servers
limited to only one programming language
Distributed asynchronous architecture pattern used to produce highly scalable applications.
Topologies
Mediator
Broker
Separates the business logic from application data and presentation
Model, View, Presenter
Replace Controller with Presenter
Presenter refers back to the view while Controller doesn’t
Presenter refers to a View's mock
http://martinfowler.com/eaaDev/PassiveScreen.html
http://martinfowler.com/eaaDev/SupervisingPresenter.html
Creates a new model, beside the domain model.
New problem
: that has to be independently testable
A view-model has no idea what view is displaying it, but more importantly no idea where its data is coming from.
Views
display a certain shape of data. They have no idea where the data comes from.
ViewModels
hold a certain shape of data and commands
Sorry Trygve Reenskaug!
Cloud Architectures
CQRS - Command & Query Responsibility Segregation
http://www.oreilly.com/programming/free/files/software-architecture-patterns.pdf
Minimizes the factors that limit application scaling
Sometimes referred to as the cloud architecture pattern
Space-based pattern
Concept of
tuple space
, the idea of distributed shared memory
LINEAR SCALABILITY
Distributed memory model for interprocess coordination and communication
Principle that an object's methods should be either commands or queries.
Applies to software systems that must be able to adapt to changing system requirements.
Separates a minimal functional core from extended functionality and customer-specific parts
Plugin Architecture
The development of several applications that use similar programming interfaces that build on the same core functionality.
Encapsulate the fundamental services of your application platform in a microkernel component
Structure
"Developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API"
Martin Fowler
Products not Projects
On completion the software is handed over to a maintenance organization and the project team that built it is disbanded.
Notion that a team should own a product over its full lifetime
http://martinfowler.com/articles/microservices.html
What's the application's deployment architecture?
Decompose the application into a set of collaborating services.
Service communicate using either synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP.
Services are developed and deployed independently of one another.
Each service has its own database in order to be decoupled from other services.
Common
Updates to the data and requests for data are executed against the same set of entities in a single data repository
All create, read, update, and delete (CRUD) operations are applied to the same representation of the entity
Problems!!
Data contention in a collaborative domain
caused by concurrent updates when optimistic locking is used.
Might expose data in the wrong context.
https://msdn.microsoft.com/en-us/library/ms978509.aspx
Solution
A pattern that segregates the operations that read data (Queries) from the operations that update data (Commands)
The data models used for querying and updates are different.
Fuente: https://msdn.microsoft.com/en-us/library/dn568103.aspx
When to Use this Pattern
Collaborative domains where multiple operations are performed in parallel on the same data
Task-based user interfaces
complex domain models, familiarity with domain-driven design (DDD) techniques
Scenarios where performance of data reads must be fine-tuned separately from performance of data writes
Scenarios where the system is expected to evolve over time and may contain multiple versions of the model, or where business rules change regularly.
Characteristics
Broadcast Communications
Real Time
Asynchrony
Fine Grained Events
Hierarchy
Complex Events Processing
Full transcript