Curated list of awesome articles and resources to learn and practice software architecture, patterns and principles. This repository will be updated continuously, keep yourself up to date .
I created this repository to share a set of links that I found valuable and inspiring and I share them with others to improve our knowledge together ✌️.
🚀 Go ahead to the official web page here: > 🌐 https://awesome-architecture.com
- Contents
- Software Architecture
- Actor Model Architecture
- Algorithms
- AI
- Clean Architecture
- Onion Architecture
- Hexagonal Architecture
- Vertical Slice Architecture
- Event Driven Architecture
- Service Oriented Architecture
- Domain Driven Design
- Data Driven Design
- CQRS
- Microservices
- Modular Monolith
- Architectural Design Principles
- Design Patterns
- Cloud Design Patterns
- Cloud Best Practices
- Cloud Native
- Platform as a Service
- Infrastructure as a Service
- DevOps
- Reverse Proxy - Load Balancing
- Service Discovery And Registry
- Service Mesh
- Object Oriented Design
- Systems Design
- Scaling
- Back Pressure
- Clean Code
- Abstraction
- Design Best Practices
- Anti Patterns
- Eventual Consistency
- Messaging
- Distributed Transactions
- Distributed Locking
- Eventual Consistency
- RESTful API Design
- gRPC
- Caching
- Functional Programming
- Concurrency
- Sharding
- Refactoring
- Database
- Relational Database
- Microsoft Azure Cloud
- Modeling
- Open Source
- Code Review
- Interview
- Architecture Decision Records (ADR)
- Micro-Frontend
- Others
- 🙏 Special Thanks
- ⭐ Support
- 🤝 Contribution
Note: Bellow contents is not complete yet and it's in progress, and I will complete the descriptions over the time, but you are feel free to contribute this part.
| Topic | Description |
|---|---|
| Software Architecture | Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. |
| Topic | Description |
|---|---|
| Actor Model Architecture | The Actor Model is a programming paradigm in which the basic unit of execution is the actor. In the Actor Model, an actor does work by using messages to express actions upon a system or other actors within the given system |
| Akka .NET | Akka.NET is a toolkit and runtime for building highly concurrent, distributed, and fault tolerant event-driven applications on .NET. |
| Microsoft Orleans | Orleans is a cross-platform framework for building robust, scalable distributed applications. |
| ProtoActor | Ultra fast distributed actors for Go, C# and Java/Kotlin. |
| Topic | Description |
|---|---|
| Algorithms | An algorithm is a procedure used for solving a problem or performing a computation. |
| Topic | Description |
|---|---|
| AI | Artificial intelligence topics |
| AI - RAG | Retrieval-Augmented Generation (RAG) |
| Topic | Description |
|---|---|
| Clean Architecture | The Clean Architecture is the system architecture guideline proposed by Robert C. Martin (Uncle Bob) derived from many architectural guidelines like Hexagonal Architecture, Onion Architecture, etc... |
| Topic | Description |
|---|---|
| Onion Architecture | The Onion architecture, introduced by Jeffrey Palermo, and it is a form of layered architecture and we can visualize these layers as concentric circles. |
| Topic | Description |
|---|---|
| Hexagonal Architecture | The Hexagonal Architecture or Ports and Adapters architecture, introduced by Alistair Cockburn and it's an architectural pattern that allows input by users or external systems to arrive into the Application at a Port via an Adapter, and allows output to be sent out from the Application through a Port to an Adapter. |
| Topic | Description |
|---|---|
| Vertical Slice Architecture | The vertical slice architecture is a technique that helps us build maintainable applications by separating the application around features or vertical slices. |
| Topic | Description |
|---|---|
| Event Driven Architecture | Event-driven architecture is a software design pattern in which decoupled applications can asynchronously publish and subscribe to events via an event broker. |
| Topic | Description |
|---|---|
| Service Oriented Architecture | Service Oriented Architecture (SOA) is a software architecture design pattern in which application components provide services to other components using a communication protocol over a network. SOA aims to achieve loose coupling between software components, allowing them to be easily replaced or updated without affecting the rest of the system. |
| Topic | Description |
|---|---|
| Domain Driven Design | The key concepts and principles of Domain Driven Design, which emphasizes the importance of building a software system around a shared understanding of the business domain and the use of ubiquitous language. |
| Value Objects | The concept of value objects in Domain Driven Design, which are immutable objects that represent a concept or measurement and are characterized by their value, rather than their identity. |
| Aggregation | The concept of aggregation in Domain Driven Design, which is a way of grouping objects together to form a logical unit that can be treated as a single entity. |
| Anemic Domain Model | The Anemic Domain Model anti-pattern in Domain Driven Design, which refers to a model where the domain objects contain little or no behavior and the business logic is instead implemented in separate services. |
| Rich Domain Model | The Rich Domain Model pattern in Domain Driven Design, which advocates for placing behavior and business logic in the domain objects themselves, rather than in separate services. |
| Domain Model | The Domain Model concept in Domain Driven Design, which is a representation of the core concepts, entities, and relationships that make up a business domain. |
| Domain Service | The Domain Service concept in Domain Driven Design, which is a stateless, transactional operation that performs a business task and is not associated with any specific entity. |
| Application Service | The Application Service concept in Domain Driven Design, which is responsible for coordinating the execution of multiple domain services to achieve a higher-level business goal. |
| Domain Events | The Domain Events concept in Domain Driven Design, which are messages that represent a significant occurrence within the business domain and can be used to trigger downstream processes or updates to other systems. |
| Integration Events | The Integration Events concept in Domain Driven Design, which are messages that represent a significant occurrence in the context of an external system and can be used to trigger downstream processes or updates to the local system. |
| Bounded Context | The Bounded Context concept in Domain Driven Design, which is a way of dividing a large, complex business domain into smaller, more manageable parts that are defined by a common language, context, and set of boundaries. |
| Infrastructure | The Infrastructure concept in Domain Driven Design, which includes all the components and systems that support the operation of the application, such as databases, message brokers, and third-party services. |
| Tactical Design Patterns | The Tactical Design Patterns in Domain Driven Design, which are recurring solutions to common problems that arise when building domain models, services, and repositories. |
| Strategic Design Patterns | The Strategic Design Patterns in Domain Driven Design, which are high-level principles and patterns that guide the overall architecture and organization of a large, complex software system. |
| Mappings | The concept of mappings in Domain Driven Design, which are the mechanisms used to transform data between the domain model and other parts of the system, such as the database or user interface. |
| Domain Primitives | The Domain Primitives concept in Domain Driven Design, which are simple, immutable value types that represent basic concepts in the domain, such as dates, times, and quantities. |
| Enum | The Enum concept in Domain Driven Design, which is a special type of domain primitive that represents a discrete set of values. |
| Exception and Validation | The concepts of exception handling and validation in Domain Driven Design, which are important mechanisms for ensuring the correctness and robustness of the application. |
| Topic | Description |
|---|---|
| Data Driven Design | Data-Driven Design is a software development methodology that emphasizes the use of data and analytics to inform design decisions. It involves collecting, analyzing, and using data to create and improve software products, services, and experiences. This approach relies on empirical evidence to guide design choices, and it requires a strong data infrastructure and analytics capabilities. Data-Driven Design can help organizations create more effective, efficient, and user-friendly products and services by making informed decisions based on real-world data. It can also lead to better customer engagement, increased revenue, and improved user satisfaction. |
| Topic | Description |
|---|---|
| CQRS | CQRS (Command Query Responsibility Segregation) is a design pattern that separates the concerns of command execution and data querying in a system. The basic idea behind CQRS is to split the application model into two separate models: one for reading data and another for writing data. This allows the two models to be optimized for their specific purposes, and provides benefits such as better scalability, performance, and maintainability. The CQRS pattern is often used in conjunction with event sourcing, which is a technique for capturing all changes to an application state as a sequence of events. Together, CQRS and event sourcing can provide a powerful way to build highly scalable and fault-tolerant systems. |
| Topic | Description |
|---|---|
| Microservices | A brief introduction to the concept of microservices, including their benefits and drawbacks, as well as common characteristics of microservices architecture. |
| Communication | An overview of the different communication patterns and protocols that can be used in microservices architecture, such as synchronous vs. asynchronous communication, REST vs. message-based communication, and the use of service buses. |
| Composite UI | A discussion of the Composite UI pattern, which involves combining multiple microservices into a single user interface, and the different approaches to implementing it, such as server-side composition vs. client-side composition. |
| Service Boundaries | An exploration of how to define and enforce service boundaries in microservices architecture, including strategies for identifying service boundaries and techniques for implementing them, such as domain-driven design and bounded contexts. |
| Testing | A guide to testing microservices, including strategies for testing individual services and testing the interactions between services, as well as tools and frameworks for testing microservices. |
| API Gateway | An introduction to the concept of an API Gateway, which acts as a single entry point for clients to access multiple microservices, and the benefits and drawbacks of using an API Gateway. |
| API Gateway - Ambassador | A specific implementation of an API Gateway using the Ambassador open-source project, including an overview of its features and how to configure and deploy it. |
| API Gateway - Kong | A specific implementation of an API Gateway using the Kong open-source project, including an overview of its features and how to configure and deploy it. |
| API Gateway - Ocelot | A specific implementation of an API Gateway using the Ocelot open-source project, including an overview of its features and how to configure and deploy it. |
| Observability | An exploration of the concept of observability in microservices architecture, which involves the ability to monitor and debug distributed systems, and the different techniques and tools for achieving observability, such as logging, tracing, health checks ,and monitoring. |
| Observability - Distributed Tracing | A deep dive into the use of distributed tracing as a tool for achieving observability in microservices architecture, including an overview of how distributed tracing works, common tracing frameworks, and how to instrument microservices for tracing. |
| Observability - Monitoring | An overview of the different types of monitoring that can be used in microservices architecture, such as system monitoring, application monitoring, and business monitoring, and the different tools and approaches for monitoring microservices. |
| Observability - Diagnostics | An overview of the different techniques and tools for diagnosing and debugging issues in microservices architecture, including log analysis. |
| Observability - Logging | Logging is an important aspect of observability in microservices architecture. This topic covers different logging frameworks and strategies used for monitoring and troubleshooting distributed systems. |
| Observability - CorrelationId | Correlation ID is a technique used to track requests across multiple microservices. This topic explains what Correlation ID is and how it is implemented in a distributed system. |
| Observability - Tools - EFK | EFK stack (Elasticsearch, Fluentd, and Kibana) is a popular logging and observability solution. This topic covers the basics of EFK, how it works, and how to set it up in a microservices architecture. |
| Observability - Tools - ELK | ELK stack (Elasticsearch, Logstash, and Kibana) is another popular logging and observability solution. This topic covers the basics of ELK, how it works, and how to set it up in a microservices architecture. |
| Observability - Tools - Fluent Bit | Fluent Bit is a lightweight and efficient log processor and forwarder. This topic covers the basics of Fluent Bit, how it works, and how to set it up in a microservices architecture. |
| Observability - Tools - FluentD | Fluentd is an open-source log collector and aggregator. This topic covers the basics of Fluentd, how it works, and how to set it up in a microservices architecture. |
| Observability - Tools - Loki | Loki is a horizontally-scalable, highly-available log aggregation system. This topic covers the basics of Loki, how it works, and how to set it up in a microservices architecture. |
| Resiliency | Resiliency is the ability of a system to recover from failures and continue functioning. This topic covers different resiliency patterns and strategies used for building fault-tolerant microservices. |
| Resiliency - Idempotency | Idempotency is a technique used to ensure that an operation can be safely retried without causing unintended effects. This topic explains what idempotency is and how it can be implemented in a microservices architecture. |
| Resiliency - High Availability | High availability is a property of a system that ensures it remains operational even in the face of hardware or software failures. This topic covers different high availability patterns and strategies used for building fault-tolerant microservices. |
| Security | Security is a critical aspect of any distributed system. This topic covers different security challenges and strategies used for securing microservices. |
| Security - Key Vault | A key vault is a secure storage location for storing cryptographic keys, certificates, and secrets used by a microservices architecture. This topic explains what a key vault is and how to use it to securely manage sensitive data in a microservices |
| Tools - CAP | CAP (short for "CAPability") is a distributed transaction solution for microservices that is based on the idea of eventual consistency. It provides an event bus with an Outbox pattern, which allows you to publish messages/events to multiple microservices in a reliable and transactional way. CAP is written in .NET Core |
| Tools - Dapr | Dapr (Distributed Application Runtime) is an open-source framework for building microservices-based applications. It provides a set of building blocks, such as state management, pub/sub messaging, and service-to-service invocation, that help developers to focus on writing business logic rather than infrastructure code. Dapr is designed to be language-agnostic and can be used with any programming language and any cloud or edge environment. This topic covers the key features of Dapr and how to use it to build distributed applications. |
| Tools - Mass Transit | Mass Transit is an open-source distributed application framework for .NET. It provides a set of abstractions and building blocks for building scalable and fault-tolerant microservices-based applications. Mass Transit supports various messaging technologies, such as RabbitMQ, ActiveMQ, and Azure Service Bus, and provides features such as request-response, pub/sub messaging, and message routing. This topic covers the key features of Mass Transit and how to use it to build distributed applications. |
| Tools - NService Bus | NService Bus is a commercial distributed application framework for .NET. It provides a set of abstractions and building blocks for building scalable and reliable microservices-based applications. NService Bus supports various messaging technologies, such as RabbitMQ, Azure Service Bus, and Amazon SQS, and provides features such as request-response, pub/sub messaging, and message routing. This topic covers the key features of NService Bus and how to use it to build distributed applications. |
| Tools - SteelToe | Steeltoe is an open-source framework for building .NET microservices-based applications that run on Cloud Foundry and Kubernetes. Steeltoe provides a set of libraries and building blocks, such as service discovery, circuit breakers, and security, that help developers to build and operate cloud-native applications. Steeltoe is designed to be modular and can be used with any .NET framework, such as ASP.NET, .NET Core, and .NET Framework. This topic covers the key features of Steeltoe and how to use it to build cloud-native applications. |
| Tools - Tye | Tye is an open-source development tool for building, testing, and deploying microservices-based applications. Tye provides a simple and fast way to develop and run applications locally using containers, without the need to manage the infrastructure. Tye supports various programming languages, such as .NET, Java, and Node.js, and integrates with popular tools such as Docker, Kubernetes, and Helm. This topic covers the key features of Tye and how to use it to develop and deploy microservices-based applications locally. |
| Tools - wolverine | Wolverine is an open-source project that provides a next-generation command and message bus for .NET. It allows developers to build scalable and distributed applications by enabling communication between different parts of the application through a message-based architecture. Wolverine is built on top of the Jasper Framework and provides features such as distributed command routing, message serialization, and versioning. It supports both synchronous and asynchronous message handling, and can be used with various transport protocols such as HTTP, RabbitMQ, and Azure Service Bus. |
| Topic | Description |
|---|---|
| Modular Monolith | Modular Monolith is an architectural approach that combines the advantages of monolithic and microservices architectures. It aims to build a monolithic application with a modular design that allows it to be divided into smaller, more manageable parts, each with its own clear responsibilities and interfaces. This approach allows teams to develop and deploy features independently, while still maintaining a single codebase and database. The modular design also facilitates the testing and maintenance of the application, as well as the scaling of individual modules. |
| Topic | Description |
|---|---|
| Architectural Design Principles | A comprehensive overview of the most important principles that should be considered when designing software architecture. |
| CAP | The CAP theorem, which describes the trade-offs that must be made in distributed systems between consistency, availability, and partition tolerance. |
| Cohesion | The concept of cohesion, which refers to the degree to which the elements within a module or component are related and work together to achieve a single purpose. |
| Coupling | The concept of coupling, which refers to the degree to which one module or component depends on another. |
| Command Query Separation | The Command Query Separation (CQS) principle, which recommends that methods should either change the state of an object (commands) or return a value (queries), but not both. |
| Cross Cutting Concerns | Cross-cutting concerns are features or requirements that cut across multiple components or modules in a system, such as security, logging, or transaction management. |
| Dependency Inversion | The Dependency Inversion principle, which states that high-level modules should not depend on low-level modules, but both should depend on abstractions. |
| DRY | The Don't Repeat Yourself (DRY) principle, which states that code should not be duplicated within a system, but instead should be abstracted into reusable functions or modules. |
| Encapsulation | Encapsulation is the principle of hiding implementation details of an object or module from its users, and providing a well-defined interface for interacting with it. |
| Fail Fast Design Principles | Fail-fast design principles aim to reduce the impact of errors and failures in a system, by detecting them as early as possible and stopping the execution of the system before the error propagates further. |
| Composition Over Inheritance | The Composition over Inheritance principle, which recommends favoring composition (building complex objects by combining simpler ones) over inheritance (creating new classes by extending existing ones) when designing object-oriented software. |
| GRASP | The General Responsibility Assignment Software Patterns (GRASP) are a set of guidelines for assigning responsibilities to objects and modules in a software system. |
| Interface Segregation | The Interface Segregation principle, which states that clients should not be forced to depend on interfaces they do not use, and that interfaces should be designed to be cohesive and focused on a single purpose. |
| Inversion Control | The Inversion of Control (IoC) pattern, which is a technique for decoupling the dependencies between modules or components in a system, by inverting the direction of the dependencies. |
| KISS | Keep It Simple, Stupid (KISS) is a design principle that encourages keeping systems and solutions as simple as possible to avoid unnecessary complexity and increase maintainability. |
| Open Closed Principles | The Open-Closed Principle (OCP) is a design principle that promotes the idea of writing code that is open to extension but closed to modification, meaning that new features should be added to a system without changing its existing codebase. |
| Persistence Ignorance | Persistence Ignorance (PI) is a design principle that encourages decoupling business logic from persistence logic to increase flexibility, maintainability, and testability. |
| Single Responsibility | The Single Responsibility Principle (SRP) is a design principle that advocates for a class or module to have only one reason to change, meaning it should only have one responsibility or job. |
| Strangler Fig Pattern | The Strangler Fig Pattern is an approach to software modernization that involves gradually replacing an existing system with a new one, module by module, rather than attempting to migrate it all at once. |
| Solid | SOLID is an acronym for five object-oriented design principles (Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle) that aim to make software systems more maintainable, scalable, and testable. |
| Yagni | You Aren't Gonna Need It (YAGNI) is a principle that advises against writing code for features that are not yet needed, to avoid adding unnecessary complexity to the codebase and focus on delivering only what is required. |
| Topic | Description |
|---|---|
| Design Patterns | A comprehensive list of design patterns with examples and explanations of how they can be used to solve common software design problems. |
| Adapter Pattern | The Adapter Pattern is a structural design pattern that allows objects with incompatible interfaces to work together by providing a wrapper that adapts the interface of one object to match the interface of another. Actually The Adapter acts as a wrapper between two objects. It catches calls for one object and transforms them to format and interface recognizable by the second object. |
| Builder | TODO... |
| Chain of Responsibility | TODO... |
| Command Message Pattern | TODO... |
| Command Pattern | TODO... |
| Decorator Patterns | TODO... |
| Factory Patterns | TODO... |
| Mediator Patterns | TODO... |
| Observer Patterns | TODO... |
| Query-Object Patterns | TODO... |
| Repository Pattern | TODO... |
| REPR | TODO... |
| Service Locator | TODO... |
| Singleton | TODO... |
| Specification Pattern | TODO... |
| State Pattern | TODO... |
| Strategy Patterns | TODO... |
| Transaction-Script Patterns | TODO... |
| Topic | Description |
|---|---|
| Cloud Design Patterns | TODO... |
| Ambassador Pattern | TODO... |
| Anti Corruption Layer Pattern | TODO... |
| BFF | TODO... |
| Bulkhead Pattern | TODO... |
| Circuit Breaker | TODO... |
| Exactly One Delivery | TODO... |
| Gateway Aggregation | TODO... |
| Gateway Pattern | TODO... |
| Inbox Patterns | TODO... |
| Outbox Patterns | TODO... |
| Saga Patterns | TODO... |
| Sidecar Patterns | TODO... |
| Strangler Fig Patterns | TODO... |
| Topic | Description |
|---|---|
| Cloud Best Practices | TODO... |
| Topic | Description |
|---|---|
| Cloud Native | TODO... |
| Topic | Description |
|---|---|
| Heroku | TODO... |
| Netlify | TODO... |
| OpenShift | TODO... |
| Rancher | TODO... |
| Topic | Description |
|---|---|
| Infrastructure as a Service | TODO... |
| Nomad | TODO... |
| Pulumi | TODO... |
| Terraform | TODO... |
| Topic | Description |
|---|---|
| Containerd | TODO... |
| Docker | TODO... |
| Docker - Docker Compose | TODO... |
| Kubernetes | TODO... |
| Kubernetes - Services | TODO... |
| Kubernetes - Deployment Strategies | TODO... |
| Kubernetes - Deployment Tools - ArgoCd | TODO... |
| Kubernetes - Deployment Tools - Flux | TODO... |
| Kubernetes - Deployment Tools - Helm | TODO... |
| Kubernetes - Deployment Tools - Jenkins | TODO... |
| Kubernetes - Deployment Tools - Kubernetes Operator | TODO... |
| Kubernetes - Deployment Tools - Kustomize | TODO... |
| Kubernetes - Ingress Controller | TODO... |
| Kubernetes - Ingress Controller - Nginx | TODO... |
| Kubernetes - Ingress Controller - Traefik | TODO... |
| Kubernetes - Other Tools - K3s | TODO... |
| Kubernetes - Other Tools - Kind | TODO... |
| Kubernetes - Other Tools - Tilt | TODO... |
| Topic | Description |
|---|---|
| Load Balancing | TODO... |
| Reverse Proxy | TODO... |
| Envoy | TODO... |
| HAProxy | TODO... |
| MetalLB | TODO... |
| Nginx | TODO... |
| Traefik | TODO... |
| Yarp | TODO... |
| Topic | Description |
|---|---|
| Service Discovery | TODO... |
| Consul | TODO... |
| Eureka | TODO... |
| Topic | Description |
|---|---|
| Service Mesh | TODO... |
| Istio | TODO... |
| Linkerd | TODO... |
| Maesh | TODO... |
| Topic | Description |
|---|---|
| Object Oriented Design | TODO... |
| Topic | Description |
|---|---|
| Systems Design | TODO... |
| Consistent Hash | TODO... |
| Topic | Description |
|---|---|
| Scaling | TODO... |
| Topic | Description |
|---|---|
| Back Pressure | TODO... |
| Topic | Description |
|---|---|
| Clean Code | TODO... |
| Topic | Description |
|---|---|
| Abstraction | TODO... |
| Topic | Description |
|---|---|
| Design Best Practices | TODO... |
| 12 Factor | TODO... |
| Strongly Typed Ids | TODO... |
| Thin Controllers | TODO... |
| Topic | Description |
|---|---|
| Anti Patterns | TODO... |
| Big Ball of Mud | TODO... |
| Code Smells | TODO... |
| God Object | TODO... |
| Leaky Abstractions | TODO... |
| Partial Object | TODO... |
| Static Cling | TODO... |
| Topic | Description |
|---|---|
| Eventual Consistency | TODO... |
| Topic | Description |
|---|---|
| Messaging | TODO... |
| Async APIs Documentation | TODO... |
| Messaging-patterns | TODO... |
| Kafka | TODO... |
| Rabbitmq | TODO... |
| Nats | TODO... |
| ZeroMQ | TODO... |
| Change Data Capture (CDC) | TODO... |
| Topic | Description |
|---|---|
| Distributed Transactions | TODO... |
| Topic | Description |
|---|---|
| Distributed Locking | TODO... |
| Topic | Description |
|---|---|
| Eventual Consistency | TODO... |
| Topic | Description |
|---|---|
| RESTful API Design | TODO... |
| Topic | Description |
|---|---|
| gRPC | TODO... |
| Topic | Description |
|---|---|
| Caching | TODO... |
| Topic | Description |
|---|---|
| Functional Programming | TODO... |
| Topic | Description |
|---|---|
| Concurrency | TODO... |
| Topic | Description |
|---|---|
| Sharding | TODO... |
| Topic | Description |
|---|---|
| Refactoring | TODO... |
| Topic | Description |
|---|---|
| Database - NoSQL - NoSQL | TODO... |
| Database - NoSQL - MongoDB | TODO... |
| Database - NoSQL - RavenDB | TODO... |
| Database - NoSQL - Cosmosdb | TODO... |
| Database - NoSQL - Documentdb | TODO... |
| Database - Relational - Relational Database | TODO... |
| Database - Relational - Postgres | TODO... |
| Database - Relational - SQL | TODO... |
| Database - Replication | TODO... |
| Database - Sharding | TODO... |
| Topic | Description |
|---|
| Topic | Description |
|---|---|
| Microsoft Azure Cloud | TODO... |
| AKS | TODO... |
| Azure API Management | TODO... |
| Azure App Service Plan | TODO... |
| Azure App Service | TODO... |
| Azure Arc | TODO... |
| Azure Configuration | TODO... |
| Azure Functions | TODO... |
| Azure Load Balancing | TODO... |
| Azure Logic App | TODO... |
| Azure Resource | TODO... |
| Azure Resource Manager | TODO... |
| Azure SQL Server | TODO... |
| Azure Security - Azure Key Vault | TODO... |
| Azure Security - Azure Active Directory | TODO... |
| Azure Messaging | TODO... |
| Azure Messaging - Azure Service Bus | TODO... |
| Azure Messaging - Azure Event Grid | TODO... |
| Azure Messaging - Azure Event Hub | TODO... |
| Azure Messaging - Azure Queue | TODO... |
| Azure Messaging - Azure Web Pub Sub | TODO... |
| Azure NoSQL | TODO... |
| Azure NoSQL - CosmosDB | TODO... |
| Azure Storage | TODO... |
| Azure Storage - Blob Storage | TODO... |
| Azure Storage - File Storage | TODO... |
| Azure Storage - Queue Storage | TODO... |
| Azure Storage - Table Storage | TODO... |
| Topic | Description |
|---|---|
| Modeling | TODO... |
| Architecture Diagram | TODO... |
| Class Diagram | TODO... |
| Component Diagram | TODO... |
| Conceptual Modeling | TODO... |
| Data Model Notations | TODO... |
| Domain Stroytelling | TODO... |
| ER Diagrams | TODO... |
| Event Modeling | TODO... |
| Event Storming | TODO... |
| Logical Modeling | TODO... |
| Topic | Description |
|---|---|
| Open Source | TODO... |
| Topic | Description |
|---|---|
| Code Review | TODO... |
| Topic | Description |
|---|---|
| Interview | TODO... |
| Topic | Description |
|---|---|
| Architecture Decision Records (ADR) | TODO... |
| Topic | Description |
|---|---|
| Micro-Frontend | Micro-frontends are revolutionizing the development landscape by allowing independent implementation of a business subdomain, all with the same and different technologies. |
| Topic | Description |
|---|---|
| Others | TODO... |
Thanks to the authors of the links for their valuable content, I gather them in one place for finding topics to read easier.
If you like, feel free to ⭐ this repository, it helps out :)
Thanks a bunch for supporting me!
Contributions are always welcome! Please take a look at the contribution guidelines pages first.
Thanks to all contributors, you're awesome and this wouldn't be possible without you! The goal is to build a categorized community-driven collection of very well-known resources.
