DOCSEARCHbyAlgolia
Submit Docs

practical.cleanarchitecture

repository·master·Indexed 25 days ago

https://github.com/phongnguyend/practical.cleanarchitecture

A demonstration repository showcasing software architecture patterns, including Clean Architecture, Hexagonal, Onion, and Vertical Slice Architecture. The project includes detailed guides for provisioning Azure infrastructure using Bicep and Azure CLI, configuring app settings for WebAPI and WebMVC services, and deploying to Azure Container Apps or Azure Kubernetes Service (AKS).

Tokens
49.4K
Snippets
115
Records
233
Agent score
81%

What's inside practical.cleanarchitecture

  1. Understand Architectural Patterns in Practical Clean Architecture

    master

    This repository provides visual and code-based demonstrations of various software architecture patterns. Use these patterns as reference models for structuring your applications.

    Note: The code samples in this repository demonstrate multiple ways and patterns to achieve tasks; they may not always represent the single best practice or the recommended approach for every specific situation.

    Key architectural concepts covered include:

    • Database Centric vs Domain Centric Architecture: Comparing approaches where the database drives the design versus where the business logic (domain) drives it.
    • Hexagonal Architecture (Ports and Adapters): Decoupling the core logic from external concerns like databases or UIs using ports and adapters.
    • Onion Architecture: A pattern focusing on placing the domain at the center, with dependencies pointing inward.
    • Clean Architecture: A specific implementation of layered architecture that emphasizes independence from frameworks, UI, and databases.
    • Classic Three-layer vs Modern Four-layer Architecture: Comparing traditional layered approaches with more modern, decoupled structures.
    • Vertical Slice Architecture (Modular Monolith): Organizing code by business features (slices) rather than technical layers to improve modularity and scalability.

  2. Overview of OAuth 2.0 Flows

    master

    OAuth 2.0 defines several flows (grant types) depending on the type of client and the security requirements. These are categorized into two main groups:

    Redirect Flows

    Used when the client needs to redirect the user to an authorization server.

    • Authorization Code Flow: The most secure flow, typically used for web applications where the client can keep a client_secret secure.
    • Implicit Flow: A simplified flow where the access token is returned directly in the redirect, typically used for native or local clients (though largely superseded by Authorization Code with PKCE).

    Credential Flows

    Used when the client handles user credentials or machine-to-machine communication.

    • Resource Owner Password Credentials Flow: The client collects the user's username and password directly. This should only be used for highly trusted applications.
    • Client Credentials Flow: Used for machine-to-machine communication where no human user is involved (e.g., a service talking to another service).

  3. Understand how a dependency framework works

    master

    A dependency framework automates the creation and initialization of objects at runtime. It utilizes a container, which acts as a central registry for mapping interfaces to their specific implementations.

    When the application starts, the framework inspects the registered types in the container and automatically constructs the necessary object graphs required by the application's components.

  5. Understand the different types of automated tests

    master

    Automated testing involves writing code to test your production code. There are three primary levels of testing:

    • Unit Test: Tests a single unit of an application in isolation, without external dependencies (files, databases, web services, etc.). They are fast and cheap to execute.
    • Integration Test: Tests the application alongside its concrete external dependencies. These provide more confidence but take longer to execute.
    • End-to-End (E2E) Test: Drives the application through its UI. These are slow and brittle, as small UI changes can break them.

    Use a Unit Test Framework to provide utility libraries for writing tests and a test runner to execute them and report results.

  6. Characteristics of good unit tests

    master

    To ensure unit tests are effective and maintainable, follow these principles:

    • Single Responsibility: Each test should focus on one thing and contain minimal lines of code.
    • No Logic: Avoid conditional statements (if), loops, or complex logic within the test itself. Simply call a method and make an assertion.
    • Isolation: Tests must be independent. They should not call each other and must not rely on state created by a previous test.
    • Appropriate Granularity: Tests should not be too specific (testing implementation details) or too general (testing too many things at once).
    • Trustworthiness: A test is trustworthy if a pass guarantees the code works and a failure accurately identifies a bug.

  9. Understand the Interface Segregation Principle (ISP)

    master
    The Interface Segregation Principle states that clients should not be forced to depend on methods they do not use. Instead of creating large, 'fat' interfaces that cover many different behaviors, split them into smaller, more specific interfaces so that implementers only need to care about the methods relevant to them.

  10. Understand the Open/Closed Principle (OCP)

    master

    The Open/Closed Principle states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.

    To follow this principle:

    • Change behavior by adding new code rather than by modifying existing code.
    • Keep frequently changing elements separate from elements that remain stable.

  11. What to test and what not to test

    master

    Focus your testing efforts on the outcomes of your methods based on their purpose:

    • Queries: Verify that the function returns the correct value. If there are multiple execution paths, test every path.
    • Commands: Verify the outcome of the action. If it changes an in-memory state, check the object's new state. If it interacts with an external dependency (database/web service), verify that the class makes the correct call to that dependency.

    Do NOT test:

    • Language features (e.g., C# language syntax).
    • Third-party code or libraries (e.g., Entity Framework).

  12. Understand Bootstrap's distribution files

    master

    The dist/ directory contains the compiled and minified assets. Bootstrap provides both standard and minified versions of CSS and JS, along with source maps for debugging.

    Key Files:

    • CSS: bootstrap.css (compiled) and bootstrap.min.css (minified).
    • JS: bootstrap.js (compiled) and bootstrap.min.js (minified).
    • Bundled JS: bootstrap.bundle.js and bootstrap.bundle.min.js include Popper (required for certain components), but do not include jQuery.
    • Source Maps: Files ending in .map are available for use with browser developer tools.
    bootstrap/
└── dist/
    ├── css/
    │   ├── bootstrap.css
    │   ├── bootstrap.min.css
    │   └── ...
    └── js/
        ├── bootstrap.bundle.js
        ├── bootstrap.bundle.min.js
        ├── bootstrap.js
        ├── bootstrap.min.js
        └── ...