src/linkedin-video/README.MD

# System design Video

1. Usecases and Requirements
2. Actors
3. C4 Modelling


## C4 Modelling
https://s3.amazonaws.com/static.codingthearchitecture.com/presentations/aotb2019-visualising-software-architecture-with-the-c4-model.pdf

C4 modeling is a lightweight and pragmatic approach to visualize and document the architecture of software systems. It's designed to strike a balance between providing enough detail for understanding and communicating the architecture, without overwhelming the audience with unnecessary complexity. C4 stands for Context, Containers, Components, and Code, which represent four levels of abstraction in the model.

### Levels of Abstraction

1. **Context Diagram (Level 1):**
   - *Purpose:* Provides an overview of the software system's context, showing its interactions with external entities or systems.
   - *Diagram Type:* System Context Diagram
   - *Notation:* Boxes represent the system, actors, and external systems, and lines indicate the interactions.
   - *Use Cases:* Use it for high-level discussions with stakeholders to establish the system's boundaries and external dependencies.

2. **Container Diagram (Level 2):**
   - *Purpose:* Focuses on the major containers or high-level components that make up the software system.
   - *Diagram Type:* Container Diagram
   - *Notation:* Boxes represent containers (e.g., web servers, databases), and lines show their interactions.
   - *Use Cases:* Use it to explore the high-level structure of the system and understand how containers interact.

3. **Component Diagram (Level 3):**
   - *Purpose:* Dives deeper into the internal structure of containers, illustrating the key components or services.
   - *Diagram Type:* Component Diagram
   - *Notation:* Boxes represent components (e.g., microservices, classes), and lines show their dependencies.
   - *Use Cases:* Ideal for breaking down containers into manageable components, exploring their relationships and responsibilities.

4. **Code Diagram (Level 4):**
   - *Purpose:* Represents the actual source code and its organization, usually at a finer level of detail.
   - *Diagram Type:* Code Diagram
   - *Notation:* Typically, class diagrams or package diagrams are used to show code-level structures.
   - *Use Cases:* Use it for in-depth discussions among developers or for documenting code structure within components.

### Benefits of C4 Modeling

- **Clarity:** C4 models provide a clear and consistent way to represent and communicate software architecture, making it easier for stakeholders to understand the system's structure.
- **Progressive Detail:** The four levels allow architects to start with high-level views and progressively zoom into lower-level details as needed.
- **Maintainability:** C4 models are easier to update and maintain compared to overly detailed diagrams, which can become unwieldy.
- **Collaboration:** C4 models encourage collaboration between technical and non-technical stakeholders by providing an accessible and structured representation.

### Tools

Various tools and libraries can help create C4 models, including Structurizr, PlantUML, and various drawing tools. The choice of tool depends on your preferences and project requirements.

C4 modeling is an effective way to communicate software architecture without getting bogged down in excessive detail, making it a valuable approach for architects and teams seeking clarity and effective communication.



## Reference
1. **Usecase Diagram:**
   - Identify primary actors and use cases to understand the system's high-level functionality and its interaction with external entities.

2. **Sequence Diagram:**
   - Create Sequence diagrams to illustrate the interactions and flow of messages between actors and objects over time.
   - Sequence diagrams provide a dynamic view of the system, showing how use cases are realized.

3. **Data Flow Diagram (DFD):**
   - Develop Data Flow Diagrams to model how data flows through the system, from external sources to processing and storage.
   - DFDs help in understanding data processing and transformation within the system.

4. **Domain Diagram:**
   - Identify domain entities (objects) and their relationships to represent the core concepts of the problem domain.
   - Define attributes and behavior for domain entities.

5. **Class Diagram:**
   - Map domain entities to classes in the Class diagram, specifying their attributes and methods.
   - Define associations, multiplicity, and roles to represent relationships between classes.

6. **Activity Diagram:**
   - Create Activity diagrams to model the flow of activities or processes within the system.
   - Activity diagrams help in visualizing how use cases are realized in terms of activities and workflows.

7. **State Machine Diagram:**
   - Use State Machine diagrams to model the states and transitions of objects within the system.
   - State machines are particularly useful for modeling the behavior of complex objects.

8. **Component Diagram:**
   - Develop Component diagrams to represent the physical and logical components of the system and their dependencies.
   - Component diagrams illustrate how the software is structured and organized.

9. **Deployment Diagram:**
   - Create Deployment diagrams to show the physical deployment of software components on hardware nodes.
   - Deployment diagrams help in understanding the system's deployment architecture.

10. **Package Diagram:**
    - Use Package diagrams to organize and group related classes and components into packages.
    - Package diagrams enhance the modularity and organization of the software.