mirror of
https://github.com/kamranahmedse/developer-roadmap.git
synced 2026-09-24 15:00:31 +08:00
Add missing content
This commit is contained in:
+1
@@ -0,0 +1 @@
|
||||
# Architectural Patterns
|
||||
+1
@@ -0,0 +1 @@
|
||||
# Architectural Principles
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
# Architectural Styles
|
||||
|
||||
Architectural styles in software refer to the overall design and organization of a software system, and the principles and patterns that are used to guide the design. These styles provide a general framework for the design of a system, and can be used to ensure that the system is well-structured, maintainable, and scalable.
|
||||
|
||||
Some common architectural styles in software include:
|
||||
|
||||
- Microservices: where the system is built as a collection of small, independent, and loosely-coupled services.
|
||||
- Event-Driven: where the system reacts to specific events that occur, rather than being continuously polled for changes.
|
||||
- Layered: where the system is divided into a set of layers, each of which has a specific responsibility and communicates with the other layers through well-defined interfaces.
|
||||
- Service-Oriented: where the system is built as a collection of services that can be accessed over a network.
|
||||
- Data-Centric: where the system is focused on the storage, retrieval and manipulation of data, rather than the processing of data.
|
||||
- Component-Based: where the system is composed of reusable and independent software components.
|
||||
- Domain-Driven: where the system is organized around the core business domain and business entities.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@What is Software Architecture & Styles?](https://study.com/academy/lesson/software-architecture-styles-patterns-components.html)
|
||||
- [@video@Types of Architectural Styles in Software Engineering](https://www.youtube.com/watch?v=2Pp0BcXN9YY)
|
||||
- [@video@10 Architecture Patterns Used In Enterprise Software Development Today](https://www.youtube.com/watch?v=brt3ao8bvqy)
|
||||
+10
@@ -0,0 +1,10 @@
|
||||
# Class Invariants
|
||||
|
||||
A class invariant is a set of conditions that must be true for any object of a class, at any point in time. In object-oriented programming (OOP), class invariants are used to define the valid states of an object and to ensure that the object always remains in a valid state.
|
||||
|
||||
Class invariants are typically defined in the constructor of a class and are enforced through the use of private methods and data members that are used to validate the state of the object. They are also checked in the class's methods before and after any operation that can change the state of the object.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@Overview of Class invariant](https://en.wikipedia.org/wiki/Class_invariant)
|
||||
- [@article@The concept of class invariant in object-oriented programming](https://arxiv.org/abs/2109.06557)
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
# Clean Code Principles
|
||||
|
||||
Clean code is code that is easy to read, understand, and maintain. It follows a set of principles that are designed to make the code more readable, testable, and less error-prone. Some of the key principles of clean code include:
|
||||
|
||||
- Clarity: The code should be easy to read and understand.
|
||||
- Simplicity: The code should be as simple as possible, avoiding unnecessary complexity.
|
||||
- Comments: Comments should be used sparingly and only when necessary to explain complex or non-obvious code.
|
||||
- Naming: Variables, functions, and classes should have meaningful and descriptive names.
|
||||
- Formatting: The code should be consistently formatted to improve readability.
|
||||
- Functionality: The code should be organized into small, single-purpose functions and classes.
|
||||
- Error handling: The code should handle errors in a consistent and predictable way.
|
||||
- Testing: The code should be testable and have a high test coverage.
|
||||
- Reusability: The code should be designed to be reusable and modular.
|
||||
- Performance: The code should be designed to be efficient and performant.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@Introduction to Clean Code & Software Design Principles](https://workat.tech/machine-coding/tutorial/introduction-clean-code-software-design-principles-nwu4qqc63e09)
|
||||
- [@feed@Explore top posts about General Programming](https://app.daily.dev/tags/general-programming?ref=roadmapsh)
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
# Clean Code Principles
|
||||
|
||||
Clean code is code that is easy to read, understand, and maintain. It follows a set of principles that are designed to make the code more readable, testable, and less error-prone. Some of the key principles of clean code include:
|
||||
|
||||
- Clarity: The code should be easy to read and understand.
|
||||
- Simplicity: The code should be as simple as possible, avoiding unnecessary complexity.
|
||||
- Comments: Comments should be used sparingly and only when necessary to explain complex or non-obvious code.
|
||||
- Naming: Variables, functions, and classes should have meaningful and descriptive names.
|
||||
- Formatting: The code should be consistently formatted to improve readability.
|
||||
- Functionality: The code should be organized into small, single-purpose functions and classes.
|
||||
- Error handling: The code should handle errors in a consistent and predictable way.
|
||||
- Testing: The code should be testable and have a high test coverage.
|
||||
- Reusability: The code should be designed to be reusable and modular.
|
||||
- Performance: The code should be designed to be efficient and performant.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@Introduction to Clean Code & Software Design Principles](https://workat.tech/machine-coding/tutorial/introduction-clean-code-software-design-principles-nwu4qqc63e09)
|
||||
- [@feed@Explore top posts about General Programming](https://app.daily.dev/tags/general-programming?ref=roadmapsh)
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
# Commands Queries
|
||||
|
||||
The Command and Query Responsibility Segregation (CQRS) pattern is a technique used in enterprise application development to separate the responsibilities of handling command (write) operations and query (read) operations for performing actions that change the state of the system, such as creating, updating, or deleting data. These operations are handled by Command Handlers, which are responsible for validating the data and executing the appropriate business logic.
|
||||
|
||||
Queries are used for retrieving data from the system, such as reading data from a database or a cache. These operations are handled by Query Handlers, which are responsible for executing the appropriate query and returning the data to the caller.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@Get Started with CQRS Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs)
|
||||
+17
@@ -0,0 +1,17 @@
|
||||
# Design Patterns
|
||||
|
||||
Design patterns are general solutions to common problems that arise in software development. They provide a way to describe and communicate proven solutions to common design problems and they provide a common vocabulary for design. They are not specific to any particular programming language or technology, but rather describe the problem and the solution in a way that can be applied to many different contexts.
|
||||
|
||||
There are several different types of design patterns, including:
|
||||
|
||||
- Creational patterns
|
||||
- Structural patterns
|
||||
- Behavioral patterns
|
||||
- Architectural patterns
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@video@What Are Design Patterns?](https://www.youtube.com/watch?v=BWprw8UHIzA)
|
||||
- [@article@Overview - Software Design Pattern](https://en.wikipedia.org/wiki/Software_design_pattern)
|
||||
- [@article@Explaining, imaging and simplifying design patterns](https://refactoring.guru/design-patterns/what-is-pattern)
|
||||
- [@feed@Explore top posts about Design Patterns](https://app.daily.dev/tags/design-patterns?ref=roadmapsh)
|
||||
+2
@@ -0,0 +1,2 @@
|
||||
# Design Principles
|
||||
|
||||
+2
@@ -0,0 +1,2 @@
|
||||
# Design Principles
|
||||
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
# Enterprise Patterns
|
||||
|
||||
Enterprise patterns are a set of design patterns that are commonly used in the development of enterprise software applications. These patterns provide a common vocabulary and a set of best practices for solving common problems that arise in the development of large, complex software systems. Some examples of enterprise patterns include:
|
||||
|
||||
- Domain-Driven Design (DDD)
|
||||
- Model-View-Controller (MVC)
|
||||
- Service Oriented Architecture (SOA)
|
||||
- Command and Query Responsibility Segregation (CQRS)
|
||||
- Event Sourcing
|
||||
- Microservices
|
||||
- Event-Driven Architecture (EDA)
|
||||
|
||||
These patterns can help to improve the maintainability and scalability of the software, by providing a clear separation of concerns and allowing for a more modular and flexible architecture.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@Software Architecture Patterns in Enterprise Software](https://blog.devgenius.io/10-software-architecture-patterns-in-enterprise-software-development-fabacb5ed0c8)
|
||||
- [@video@What are Enterprise Integration Patterns?](https://www.youtube.com/watch?v=WNm3QmJadNs)
|
||||
- [@feed@Explore top posts about Enterprise](https://app.daily.dev/tags/enterprise?ref=roadmapsh)
|
||||
+18
@@ -0,0 +1,18 @@
|
||||
# Keep Framework Code Distant
|
||||
|
||||
Keeping framework code distant refers to separating the application's code from the framework's code. By doing so, it makes it easier to maintain, test, and upgrade the application's codebase and the framework independently.
|
||||
|
||||
Here are some ways to keep framework code distant in system architecture:
|
||||
|
||||
1. Use an abstraction layer to separate the application code from the framework code. This allows the application code to be written without the need to know the specifics of the framework.
|
||||
2. Use dependency injection to decouple the application code from the framework code. This allows the application code to use the framework's functionality without having to instantiate the framework objects directly.
|
||||
3. Avoid using framework-specific libraries or classes in the application code. This makes it easier to switch to a different framework in the future if needed.
|
||||
4. Use a standard interface for the application code to interact with the framework. This allows the application code to be written without the need to know the specifics of the framework.
|
||||
5. Keep the application and the framework code in separate projects and/or repositories.
|
||||
|
||||
By following these best practices, the system architecture will be more maintainable, testable, and less error-prone, and it will be easier to upgrade or switch the framework if needed.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@Clean architecture](https://pusher.com/tutorials/clean-architecture-introduction/)
|
||||
- [@feed@Explore top posts about General Programming](https://app.daily.dev/tags/general-programming?ref=roadmapsh)
|
||||
+3
@@ -0,0 +1,3 @@
|
||||
# Keep it Small
|
||||
|
||||
You should design and implement small, focused components that serve a specific purpose, rather than large, monolithic components that try to do everything. This can help to improve the maintainability and scalability of the system by making it easier to understand, test, and modify individual components.
|
||||
+1
@@ -0,0 +1 @@
|
||||
# Law of Demeter
|
||||
+7
@@ -0,0 +1,7 @@
|
||||
# Meaningful Names
|
||||
|
||||
You should follow the practice of giving clear and descriptive names to different components of a system, such as variables, functions, and classes. This can help to make the system more understandable and maintainable by clearly communicating the purpose of each component and its intended usage.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@A Guide for Naming Things in Programming](https://levelup.gitconnected.com/a-guide-for-naming-things-in-programming-2dc2d74879f8)
|
||||
+10
@@ -0,0 +1,10 @@
|
||||
# Message Queues Streams
|
||||
|
||||
Message queues and streams are architectural patterns that are used to decouple different components of a system and enable asynchronous communication between them.
|
||||
|
||||
Message Queues: A message queue is a software component that allows multiple systems or applications to communicate with each other by passing messages between them. Messages are stored in a queue, and each message is processed by a single consumer. This pattern is useful for systems where there is a high degree of variability in the rate of message production and consumption, and where the sender and receiver do not need to be active at the same time. Examples of message queue systems are Apache Kafka, RabbitMQ, and Amazon SQS.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@System Design — Message Queues](https://medium.com/must-know-computer-science/system-design-message-queues-245612428a22)
|
||||
- [@article@Overview of Message Queue pattern](https://badia-kharroubi.gitbooks.io/microservices-architecture/content/patterns/communication-patterns/message-queue-pattern.html)
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
# Object Oriented Programming
|
||||
|
||||
Object-oriented programming (OOP) is a programming paradigm that is based on the concept of "objects," which are instances of a class. In OOP, a class is a blueprint for creating objects, which have both data (attributes) and behavior (methods). The main idea behind OOP is to model real-world objects and their interactions, making it well-suited for creating complex and large-scale software systems.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@Discover Object Oriented Programming](https://opendsa.cs.vt.edu/ODSA/Books/Everything/html/IntroOO.html)
|
||||
- [@video@Software Development Tutorial - What is object-oriented language?s](https://www.youtube.com/watch?app=desktop\&v=SS-9y0H3Si8)
|
||||
- [@feed@Explore top posts about General Programming](https://app.daily.dev/tags/general-programming?ref=roadmapsh)
|
||||
+1
@@ -0,0 +1 @@
|
||||
# Organize code by actor it belongs to
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
# Programming Paradigms
|
||||
|
||||
A programming paradigm is a fundamental style or approach to solving problems using a programming language. Different programming paradigms provide different ways of organizing and structuring code, and have different strengths and weaknesses. Some of the most common programming paradigms include:
|
||||
|
||||
- Imperative programming
|
||||
- Functional programming
|
||||
- Object-oriented programming
|
||||
- Logic programming
|
||||
- Declarative programming
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@Overview of Programming paradigm](https://en.wikipedia.org/wiki/Programming_paradigm)
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
# Scope Visibility
|
||||
|
||||
Scope visibility refers to the accessibility or visibility of variables, functions, and other elements in a program, depending on the context in which they are defined. In object-oriented programming (OOP), scope visibility is controlled through the use of access modifiers, such as "public," "private," and "protected."
|
||||
|
||||
- Public: A public element can be accessed from anywhere in the program, both within the class and outside of it.
|
||||
- Private: A private element can only be accessed within the class in which it is defined. It is not accessible to other classes, even if they inherit from the class.
|
||||
- Protected: A protected element can only be accessed within the class and its subclasses.
|
||||
|
||||
There are variations of scope visibility based on the programming language, but these are the most common.
|
||||
+1
@@ -0,0 +1 @@
|
||||
# Tell, don't ask
|
||||
+1
@@ -0,0 +1 @@
|
||||
# Tests should be fast and independent
|
||||
+16
@@ -0,0 +1,16 @@
|
||||
# Use Cases
|
||||
|
||||
Use Cases are a pattern used in enterprise application development to represent the functional requirements of a system. They describe the interactions between the system and its users, and the steps that are required to accomplish a specific goal. Use cases are a way to capture the requirements of the system in a way that is easily understood by both the development team and the stakeholders.
|
||||
|
||||
A use case is a description of a sequence of actions that a system performs in response to a request from a user, in order to achieve a specific goal. A use case typically includes:
|
||||
|
||||
- The actor (user) who initiates the action
|
||||
- The goal that the actor wants to achieve
|
||||
- The steps required to achieve the goal, including any alternative paths or error conditions
|
||||
- The expected outcome of the interaction
|
||||
|
||||
Use cases are often used to drive the design and development of the system, as they provide a clear and detailed understanding of the requirements.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@Use Case Patterns](https://caminao.blog/how-to-implement-symbolic-representations/patterns/functional-patterns/use-case-patterns/)
|
||||
Reference in New Issue
Block a user