-
Notifications
You must be signed in to change notification settings - Fork 1
Architecture Principles
Majeed edited this page Nov 28, 2018
·
20 revisions
Common Architecture Styles/Patterns
- top-5-architecture Patterns
- Microservices on AWS Whitepaper
- AWS reInvent 2016 : From Monolithic to Microservices
- refactor monolith into microservice stategies
- Migrating to cloud native architectures
- Cloud Migration Strategies
- Deployment Strategies
Mostly suited for batch and event-driven workloads. Something that need variable resources for a short (not continuous) period of time.
- Awesome Serverless - List of awesome solutions and resources for serverless applications
- Serverless Framework
- AWS SAM (Serverless Application Modules)
Principles that can be applied to building applications for
- SOLID Principle
- 12 Factor & beyond 15 Factor (addition of telemetry, security and API-First)
- see Microservices patterns
Tiers are the physical deployments of Layers. Tier is a unit of deployment, where as Layer is logical separation of responsibility
- Layers are simply a way of organizing your software components (presentation, sevice etc..)
- Tier is where your layers are deployed and run
- Architectural Style
- Defines the components and connectors (the What part) - Highest level abstraction
- Not Domain Specific but applicable in a given development context
- e.g Layered, Publish-subscribe, event-driven, Client-Server
- Architectural Pattern
- Defines the implementation stratgies of those components and connectors (the How part)
- A way to implement and archictural style
- A Pattern is a general reusable solution to a recurring problem. They solve the problem related to an architectural style.
- Are domain specific
- n-tier, MVC
- Design Pattern
- More localized in their scope then Architectural Patterns
- A way to solve localized problem.
- A good architecture always uses design patterns
- Factory-method, abstract factory
Simple Factory vs Factory method vs Abstract Factory
- Design Software with High Cohesion and Low Coupling
- Design module to do what it supposed to do 'fully' - rather than doing a lot other things as well.
- Low Coupling will ensure less dependency on individual modules, each module can be managed independent or with mininmum changes in some situations.