diff --git a/src/data/roadmaps/software-design-architecture/content/abstract-classes@RMkEE7c0jdVFqZ4fmjL6Y.md b/src/data/roadmaps/software-design-architecture/content/abstract-classes@RMkEE7c0jdVFqZ4fmjL6Y.md index bdc730c62..dd5247200 100644 --- a/src/data/roadmaps/software-design-architecture/content/abstract-classes@RMkEE7c0jdVFqZ4fmjL6Y.md +++ b/src/data/roadmaps/software-design-architecture/content/abstract-classes@RMkEE7c0jdVFqZ4fmjL6Y.md @@ -4,6 +4,6 @@ An abstract class is a class in object-oriented programming (OOP) that cannot be Abstract classes are used to provide a common interface and implementation for a group of related classes. They are also used to define common behavior that must be implemented by all subclasses. A subclass that inherits from an abstract class is called a concrete class, and it must provide an implementation for all the abstract methods declared in the parent class. -Learn more from the following resources: +Visit the following resources to learn more: -- [@article@What is an Abstract Class in Object Oriented Programming](https://www.theserverside.com/definition/abstract-class) +- [@article@What is an Abstract Class in Object Oriented Programming](https://www.theserverside.com/definition/abstract-class) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/abstraction@VA8FMrhF4non9x-J3urY8.md b/src/data/roadmaps/software-design-architecture/content/abstraction@VA8FMrhF4non9x-J3urY8.md index 76fb68913..38cc50746 100644 --- a/src/data/roadmaps/software-design-architecture/content/abstraction@VA8FMrhF4non9x-J3urY8.md +++ b/src/data/roadmaps/software-design-architecture/content/abstraction@VA8FMrhF4non9x-J3urY8.md @@ -4,9 +4,9 @@ Abstraction is a concept in object-oriented programming (OOP) that refers to the There are two types of abstraction: -- Data abstraction: refers to hiding the internal representation of data and providing a simplified view of the data through a set of well-defined interfaces. -- Behavioral abstraction: refers to hiding the internal behavior of an object and providing a simplified view of its capabilities through a set of well-defined interfaces. +* Data abstraction: refers to hiding the internal representation of data and providing a simplified view of the data through a set of well-defined interfaces. +* Behavioral abstraction: refers to hiding the internal behavior of an object and providing a simplified view of its capabilities through a set of well-defined interfaces. -Learn more from the following links: +Visit the following resources to learn more: -- [@video@Tutorial - Abstraction](https://www.youtube.com/watch?v=OF55HZPE7lQ) +- [@video@Tutorial - Abstraction](https://www.youtube.com/watch?v=OF55HZPE7lQ) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/anemic-models@nVaoI4IDPVEsdtFcjGNRw.md b/src/data/roadmaps/software-design-architecture/content/anemic-models@nVaoI4IDPVEsdtFcjGNRw.md index d5e31761e..0967b813a 100644 --- a/src/data/roadmaps/software-design-architecture/content/anemic-models@nVaoI4IDPVEsdtFcjGNRw.md +++ b/src/data/roadmaps/software-design-architecture/content/anemic-models@nVaoI4IDPVEsdtFcjGNRw.md @@ -4,6 +4,6 @@ An Anemic model, also known as an anemic domain model, is a type of domain model An anemic model is considered an anti-pattern in object-oriented programming (OOP) because it violates the principles of encapsulation and separation of concerns. In an anemic model, the behavior is separated from the data, and is typically implemented in a separate service layer, which can lead to a complex, tightly coupled, and hard-to-maintain codebase. -Learn more from the following links: +Visit the following resources to learn more: -- [@article@Overview of Anemic Domain Model](https://en.wikipedia.org/wiki/Anemic_domain_model) +- [@article@Overview of Anemic Domain Model](https://en.wikipedia.org/wiki/Anemic_domain_model) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/architectural-patterns@jq916t7svaMw5sFOcqZSi.md b/src/data/roadmaps/software-design-architecture/content/architectural-patterns@jq916t7svaMw5sFOcqZSi.md index e0850f008..161af6280 100644 --- a/src/data/roadmaps/software-design-architecture/content/architectural-patterns@jq916t7svaMw5sFOcqZSi.md +++ b/src/data/roadmaps/software-design-architecture/content/architectural-patterns@jq916t7svaMw5sFOcqZSi.md @@ -2,19 +2,19 @@ Architectural patterns are a set of solutions that have been proven to work well for specific types of software systems. They provide a common vocabulary and set of best practices for designing and building software systems, and can help developers make better design decisions. Some common architectural patterns include: -- Model-View-Controller (MVC): A pattern for separating the user interface, business logic, and data storage components of a system. -- Microservices: A pattern for building systems as a collection of small, independently deployable services that communicate over a network. -- Event-Driven: A pattern for building systems that respond to events and perform actions in response. -- Layered: A pattern for organizing a system into layers, with each layer providing a specific set of services to the layer above it. -- Pipe-and-Filter: A pattern for building systems as a series of independent, reusable processing elements that are connected together in a pipeline. -- Command-Query Responsibility Segregation (CQRS): A pattern for separating the handling of commands (which change the state of the system) from the handling of queries (which retrieve information from the system) -- Blackboard: A pattern for creating a centralized repository of information that can be accessed and modified by multiple independent modules or subsystems. -- Microkernel: A pattern that aims to minimize the amount of code running in kernel mode and move as much functionality as possible into user-mode processes. -- Serverless: A design pattern that allows developers to build and run applications and services without having to provision and manage servers. -- Message Queues and Streams: A pattern that decouples different components of a system and enables asynchronous communication between them. -- Event Sourcing: A pattern that stores all changes to the system's state as a sequence of events, rather than just the current state. +* Model-View-Controller (MVC): A pattern for separating the user interface, business logic, and data storage components of a system. +* Microservices: A pattern for building systems as a collection of small, independently deployable services that communicate over a network. +* Event-Driven: A pattern for building systems that respond to events and perform actions in response. +* Layered: A pattern for organizing a system into layers, with each layer providing a specific set of services to the layer above it. +* Pipe-and-Filter: A pattern for building systems as a series of independent, reusable processing elements that are connected together in a pipeline. +* Command-Query Responsibility Segregation (CQRS): A pattern for separating the handling of commands (which change the state of the system) from the handling of queries (which retrieve information from the system) +* Blackboard: A pattern for creating a centralized repository of information that can be accessed and modified by multiple independent modules or subsystems. +* Microkernel: A pattern that aims to minimize the amount of code running in kernel mode and move as much functionality as possible into user-mode processes. +* Serverless: A design pattern that allows developers to build and run applications and services without having to provision and manage servers. +* Message Queues and Streams: A pattern that decouples different components of a system and enables asynchronous communication between them. +* Event Sourcing: A pattern that stores all changes to the system's state as a sequence of events, rather than just the current state. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Overview - Architectural Pattern](https://en.wikipedia.org/wiki/Architectural_pattern) -- [@video@Architecture Patterns Used In Enterprise Software Development](https://www.youtube.com/watch?v=BrT3AO8bVQY) +- [@video@Architecture Patterns Used In Enterprise Software Development](https://www.youtube.com/watch?v=BrT3AO8bVQY) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/architectural-principles@XBCxWdpvQyK2iIG2eEA1K.md b/src/data/roadmaps/software-design-architecture/content/architectural-principles@XBCxWdpvQyK2iIG2eEA1K.md index e5828bbc7..52d6c15b1 100644 --- a/src/data/roadmaps/software-design-architecture/content/architectural-principles@XBCxWdpvQyK2iIG2eEA1K.md +++ b/src/data/roadmaps/software-design-architecture/content/architectural-principles@XBCxWdpvQyK2iIG2eEA1K.md @@ -2,7 +2,7 @@ Architectural principles refer to a set of guidelines or rules that are used to guide the design and development of a software architecture. These principles are intended to ensure that the resulting architecture is maintainable, scalable, and easy to understand and modify. Some common architectural principles include the separation of concerns, modularity, loose coupling, and high cohesion. Additionally, architectural principles are often used in conjunction with design patterns, which are reusable solutions to common software design problems. -To learn more, visit the following links: +Visit the following resources to learn more: - [@article@Intro to Architectural Principles](https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/architectural-principles) -- [@video@Principles of Software Design](https://www.youtube.com/watch?v=TO9igqkPtfc) +- [@video@Principles of Software Design](https://www.youtube.com/watch?v=TO9igqkPtfc) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/architectural-styles@37xWxG2D9lVuDsHUgLfzP.md b/src/data/roadmaps/software-design-architecture/content/architectural-styles@37xWxG2D9lVuDsHUgLfzP.md index 4c75022ed..10dca5972 100644 --- a/src/data/roadmaps/software-design-architecture/content/architectural-styles@37xWxG2D9lVuDsHUgLfzP.md +++ b/src/data/roadmaps/software-design-architecture/content/architectural-styles@37xWxG2D9lVuDsHUgLfzP.md @@ -4,16 +4,16 @@ Architectural styles in software refer to the overall design and organization of 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. +* 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: +Visit the following resources to learn more: - [@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) +- [@video@10 Architecture Patterns Used In Enterprise Software Development Today](https://www.youtube.com/watch?v=brt3ao8bvqy) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/architectural-styles@En_hvwRvY6k_itsNCQBYE.md b/src/data/roadmaps/software-design-architecture/content/architectural-styles@En_hvwRvY6k_itsNCQBYE.md index 4c75022ed..10dca5972 100644 --- a/src/data/roadmaps/software-design-architecture/content/architectural-styles@En_hvwRvY6k_itsNCQBYE.md +++ b/src/data/roadmaps/software-design-architecture/content/architectural-styles@En_hvwRvY6k_itsNCQBYE.md @@ -4,16 +4,16 @@ Architectural styles in software refer to the overall design and organization of 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. +* 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: +Visit the following resources to learn more: - [@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) +- [@video@10 Architecture Patterns Used In Enterprise Software Development Today](https://www.youtube.com/watch?v=brt3ao8bvqy) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/avoid-passing-nulls-booleans@yyKvmutbxu3iVHTuqr5q4.md b/src/data/roadmaps/software-design-architecture/content/avoid-passing-nulls-booleans@yyKvmutbxu3iVHTuqr5q4.md index 6d2b4d1cf..1ad23bbcf 100644 --- a/src/data/roadmaps/software-design-architecture/content/avoid-passing-nulls-booleans@yyKvmutbxu3iVHTuqr5q4.md +++ b/src/data/roadmaps/software-design-architecture/content/avoid-passing-nulls-booleans@yyKvmutbxu3iVHTuqr5q4.md @@ -2,10 +2,10 @@ Passing nulls or Booleans can lead to unexpected behavior and difficult-to-debug errors in a program. Here are some ways to avoid passing nulls or Booleans in system architecture: -- Use Optionals or Maybe types instead of nulls to indicate the absence of a value. This makes it clear when a value is missing and prevents null reference exceptions. -- Use a default value for function arguments instead of allowing them to be null or Boolean. This eliminates the need to check for null or Boolean values and reduces the potential for errors. -- Use the Null Object pattern to replace null values with a special object that has a defined behavior. This eliminates the need to check for null values and makes the code more readable. -- Use the Ternary operator (?:) instead of if-else statements when working with Booleans. This can make the code more concise and easier to read. -- Use the assert function to check the validity of function arguments and throw an exception if they are invalid. +* Use Optionals or Maybe types instead of nulls to indicate the absence of a value. This makes it clear when a value is missing and prevents null reference exceptions. +* Use a default value for function arguments instead of allowing them to be null or Boolean. This eliminates the need to check for null or Boolean values and reduces the potential for errors. +* Use the Null Object pattern to replace null values with a special object that has a defined behavior. This eliminates the need to check for null values and makes the code more readable. +* Use the Ternary operator (?:) instead of if-else statements when working with Booleans. This can make the code more concise and easier to read. +* Use the assert function to check the validity of function arguments and throw an exception if they are invalid. -By following these best practices, the system architecture will be more robust and less error-prone. +By following these best practices, the system architecture will be more robust and less error-prone. \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/be-consistent@2SOZvuEcy8Cy8ymN7x4L-.md b/src/data/roadmaps/software-design-architecture/content/be-consistent@2SOZvuEcy8Cy8ymN7x4L-.md index f68cd78ec..81bc30124 100644 --- a/src/data/roadmaps/software-design-architecture/content/be-consistent@2SOZvuEcy8Cy8ymN7x4L-.md +++ b/src/data/roadmaps/software-design-architecture/content/be-consistent@2SOZvuEcy8Cy8ymN7x4L-.md @@ -2,6 +2,6 @@ Being consistent refers to maintaining a consistent pattern. This can include using consistent naming conventions, data structures, and interfaces throughout the system, as well as adhering to established design principles and best practices. Consistency can help to make the system more maintainable, understandable, and extendable. -Learn more from the following links: +Visit the following resources to learn more: -- [@article@10 Tips for Writing Clean Code](https://www.pluralsight.com/blog/software-development/10-steps-to-clean-code) +- [@article@10 Tips for Writing Clean Code](https://www.pluralsight.com/blog/software-development/10-steps-to-clean-code) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/blackboard-pattern@Kk7u2B67Fdg2sU8E_PGqr.md b/src/data/roadmaps/software-design-architecture/content/blackboard-pattern@Kk7u2B67Fdg2sU8E_PGqr.md index 06ea2115d..4642b6219 100644 --- a/src/data/roadmaps/software-design-architecture/content/blackboard-pattern@Kk7u2B67Fdg2sU8E_PGqr.md +++ b/src/data/roadmaps/software-design-architecture/content/blackboard-pattern@Kk7u2B67Fdg2sU8E_PGqr.md @@ -2,7 +2,7 @@ The Blackboard architectural pattern is a software design pattern that allows for the creation of a centralized repository of information that can be accessed and modified by multiple independent modules or subsystems. The blackboard serves as a communication and coordination mechanism between these modules, allowing them to share information and collaborate to achieve a common goal. This pattern is often used in artificial intelligence and decision-making systems, where multiple processes or agents need to share and reason over complex data. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Overview of Blackboard (design pattern)](https://en.wikipedia.org/wiki/Blackboard_(design_pattern)) -- [@article@Architectural Patterns: Blackboard](http://www.openloop.com/softwareEngineering/patterns/architecturePattern/arch_Blackboard.htm) +- [@article@Architectural Patterns: Blackboard](http://www.openloop.com/softwareEngineering/patterns/architecturePattern/arch_Blackboard.htm) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/boundaries@-Kw8hJhgQH2qInUFj2TUe.md b/src/data/roadmaps/software-design-architecture/content/boundaries@-Kw8hJhgQH2qInUFj2TUe.md index 1a9f65370..adfab902e 100644 --- a/src/data/roadmaps/software-design-architecture/content/boundaries@-Kw8hJhgQH2qInUFj2TUe.md +++ b/src/data/roadmaps/software-design-architecture/content/boundaries@-Kw8hJhgQH2qInUFj2TUe.md @@ -4,6 +4,6 @@ In software architecture, boundaries refer to the interfaces or the points of se Boundaries are important because they define the points of interaction between different components or systems, and they dictate how those components or systems will communicate with each other. By defining clear boundaries, it makes it easier to understand, test, and maintain the system, as the interactions between components or systems are well-defined and easy to reason about. -To learn more, visit the following links: +Visit the following resources to learn more: -- [@article@Boundaries in Software Architecture](https://www.open.edu/openlearn/science-maths-technology/approaches-software-development/content-section-1.1.4) +- [@article@Boundaries in Software Architecture](https://www.open.edu/openlearn/science-maths-technology/approaches-software-development/content-section-1.1.4) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/class-variants@c6n-wOHylTbzpxqgoXtdw.md b/src/data/roadmaps/software-design-architecture/content/class-variants@c6n-wOHylTbzpxqgoXtdw.md index 1ff939d56..6096becbe 100644 --- a/src/data/roadmaps/software-design-architecture/content/class-variants@c6n-wOHylTbzpxqgoXtdw.md +++ b/src/data/roadmaps/software-design-architecture/content/class-variants@c6n-wOHylTbzpxqgoXtdw.md @@ -4,8 +4,7 @@ A class invariant is a set of conditions that must be true for any object of a c 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: +Visit the following resources to learn more: - [@article@Overview of Class invariant](https://en.wikipedia.org/wiki/Class_invariant) -- [@article@Class Invariants](https://course.ccs.neu.edu/cs3500f15/lec_08_notes.html) -- [@article@The concept of class invariant in object-oriented programming](https://arxiv.org/abs/2109.06557) +- [@article@The concept of class invariant in object-oriented programming](https://arxiv.org/abs/2109.06557) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/clean-code-principles@08qKtgnhJ3tlb5JKfTDf5.md b/src/data/roadmaps/software-design-architecture/content/clean-code-principles@08qKtgnhJ3tlb5JKfTDf5.md index 1a5cf0af1..6fc81426c 100644 --- a/src/data/roadmaps/software-design-architecture/content/clean-code-principles@08qKtgnhJ3tlb5JKfTDf5.md +++ b/src/data/roadmaps/software-design-architecture/content/clean-code-principles@08qKtgnhJ3tlb5JKfTDf5.md @@ -2,18 +2,18 @@ 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. +* 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: +Visit the following resources to learn more: - [@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) +- [@feed@Explore top posts about General Programming](https://app.daily.dev/tags/general-programming?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/clean-code@TJZgsxpfOmltUUChMzlEM.md b/src/data/roadmaps/software-design-architecture/content/clean-code@TJZgsxpfOmltUUChMzlEM.md index 1a5cf0af1..6fc81426c 100644 --- a/src/data/roadmaps/software-design-architecture/content/clean-code@TJZgsxpfOmltUUChMzlEM.md +++ b/src/data/roadmaps/software-design-architecture/content/clean-code@TJZgsxpfOmltUUChMzlEM.md @@ -2,18 +2,18 @@ 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. +* 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: +Visit the following resources to learn more: - [@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) +- [@feed@Explore top posts about General Programming](https://app.daily.dev/tags/general-programming?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/client-server@ZGIMUaNfBwE5b6O1yexSz.md b/src/data/roadmaps/software-design-architecture/content/client-server@ZGIMUaNfBwE5b6O1yexSz.md index 1d19890f1..3c5cac669 100644 --- a/src/data/roadmaps/software-design-architecture/content/client-server@ZGIMUaNfBwE5b6O1yexSz.md +++ b/src/data/roadmaps/software-design-architecture/content/client-server@ZGIMUaNfBwE5b6O1yexSz.md @@ -4,6 +4,6 @@ The client-server architecture is a common architecture pattern used in distribu The client is responsible for presenting the user interface and handling user input, while the server is responsible for processing the requests and returning the appropriate response. The server can also handle tasks such as data storage, security, and business logic. -Learn more from the following links: +Visit the following resources to learn more: -- [@article@Intro to Client-server Architecture](https://cs.uwaterloo.ca/~m2nagapp/courses/CS446/1195/Arch_Design_Activity/ClientServer.pdf) +- [@article@Intro to Client-server Architecture](https://cs.uwaterloo.ca/~m2nagapp/courses/CS446/1195/Arch_Design_Activity/ClientServer.pdf) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/command-query-separation@tLbckKmfVxgn59j_dlh8b.md b/src/data/roadmaps/software-design-architecture/content/command-query-separation@tLbckKmfVxgn59j_dlh8b.md index 4600f9942..53a91840e 100644 --- a/src/data/roadmaps/software-design-architecture/content/command-query-separation@tLbckKmfVxgn59j_dlh8b.md +++ b/src/data/roadmaps/software-design-architecture/content/command-query-separation@tLbckKmfVxgn59j_dlh8b.md @@ -2,6 +2,6 @@ Command-Query Separation (CQS) is a software design principle that separates the responsibilities of a method or function into two categories: commands and queries. Commands are methods that change the state of the system, while queries are methods that return information but do not change the state of the system. -Learn more from the following links: +Visit the following resources to learn more: -- [@article@CQS Pattern](https://martinfowler.com/bliki/CommandQuerySeparation.html) +- [@article@CQS Pattern](https://martinfowler.com/bliki/CommandQuerySeparation.html) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/commands--queries@j_SUD3SxpKYZstN9LSP82.md b/src/data/roadmaps/software-design-architecture/content/commands--queries@j_SUD3SxpKYZstN9LSP82.md index 84e83f86f..393e10e40 100644 --- a/src/data/roadmaps/software-design-architecture/content/commands--queries@j_SUD3SxpKYZstN9LSP82.md +++ b/src/data/roadmaps/software-design-architecture/content/commands--queries@j_SUD3SxpKYZstN9LSP82.md @@ -4,6 +4,6 @@ The Command and Query Responsibility Segregation (CQRS) pattern is a technique u 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: +Visit the following resources to learn more: -- [@article@Get Started with CQRS Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs) +- [@article@Get Started with CQRS Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/component-based@a0geFJWl-vi3mYytTjYdb.md b/src/data/roadmaps/software-design-architecture/content/component-based@a0geFJWl-vi3mYytTjYdb.md index 942bd9b1b..7be2f789a 100644 --- a/src/data/roadmaps/software-design-architecture/content/component-based@a0geFJWl-vi3mYytTjYdb.md +++ b/src/data/roadmaps/software-design-architecture/content/component-based@a0geFJWl-vi3mYytTjYdb.md @@ -4,6 +4,6 @@ In software architecture, component-based design (CBD) is an approach to designi In CBD, a software system is divided into a set of components, each of which has a well-defined interface and a specific responsibility. These components can be developed, tested, and deployed independently, making it easier to add new features, modify existing ones, and maintain the system. -Learn more from the following links: +Visit the following resources to learn more: -- [@article@Component Based Software architecture](https://www.tutorialspoint.com/software_architecture_design/component_based_architecture.htm) +- [@article@Component Based Software architecture](https://www.tutorialspoint.com/software_architecture_design/component_based_architecture.htm) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/component-principles@8Bm0sRhUg6wZtnvtTmpgY.md b/src/data/roadmaps/software-design-architecture/content/component-principles@8Bm0sRhUg6wZtnvtTmpgY.md index 8cd892c58..3c81da966 100644 --- a/src/data/roadmaps/software-design-architecture/content/component-principles@8Bm0sRhUg6wZtnvtTmpgY.md +++ b/src/data/roadmaps/software-design-architecture/content/component-principles@8Bm0sRhUg6wZtnvtTmpgY.md @@ -2,17 +2,17 @@ Component principles in software architecture refer to guidelines for designing and implementing software components that are modular, reusable, and easy to understand, test, and maintain. Some of the key component principles in software architecture include: -- High cohesion -- Low coupling -- Separation of concerns -- Interface-based design -- Reusability -- Testability -- Modularity -- Interoperability +* High cohesion +* Low coupling +* Separation of concerns +* Interface-based design +* Reusability +* Testability +* Modularity +* Interoperability By following these component principles, software can be developed in a way that is easy to understand, maintain, and extend, and that is less prone to bugs. It also enables better code reuse, and makes it easier to test and change the code, and also enables better code reuse, as components can be reused in different contexts. -Learn more from the following links: +Visit the following resources to learn more: -- [@article@Component-Based Architecture](https://www.tutorialspoint.com/software_architecture_design/component_based_architecture.htm) +- [@article@Component-Based Architecture](https://www.tutorialspoint.com/software_architecture_design/component_based_architecture.htm) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/composition-over-inheritance@Izno7xX7wDvwPEg7f_d1Y.md b/src/data/roadmaps/software-design-architecture/content/composition-over-inheritance@Izno7xX7wDvwPEg7f_d1Y.md index 32c6ce12f..310a67d10 100644 --- a/src/data/roadmaps/software-design-architecture/content/composition-over-inheritance@Izno7xX7wDvwPEg7f_d1Y.md +++ b/src/data/roadmaps/software-design-architecture/content/composition-over-inheritance@Izno7xX7wDvwPEg7f_d1Y.md @@ -4,7 +4,7 @@ Composition over inheritance is a programming principle that suggests that it is Inheritance is a powerful mechanism for creating reusable code, but it can also lead to tightly coupled, hard-to-maintain code. This is because inherited classes are tightly bound to their parent classes and any changes made to the parent class will affect all of its child classes. This makes it hard to change or extend the code without affecting the entire class hierarchy. -Learn more from the following links: +Visit the following resources to learn more: -- [@video@Tutorial - Composition over Inheritance](https://www.youtube.com/watch?v=wfMtDGfHWpA) - [@article@Overview of Composition over Inheritance](https://en.wikipedia.org/wiki/Composition_over_inheritance) +- [@video@Tutorial - Composition over Inheritance](https://www.youtube.com/watch?v=wfMtDGfHWpA) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/concrete-classes@hd6GJ-H4p9I4aaiRTni57.md b/src/data/roadmaps/software-design-architecture/content/concrete-classes@hd6GJ-H4p9I4aaiRTni57.md index ce02f46cf..f9dfd8993 100644 --- a/src/data/roadmaps/software-design-architecture/content/concrete-classes@hd6GJ-H4p9I4aaiRTni57.md +++ b/src/data/roadmaps/software-design-architecture/content/concrete-classes@hd6GJ-H4p9I4aaiRTni57.md @@ -2,4 +2,4 @@ A concrete class is a class in object-oriented programming (OOP) that can be instantiated, meaning objects can be created from it. A concrete class is a class that provides an implementation for all of the abstract methods declared in its parent class, if it inherits from an abstract class. A concrete class can also be a class that does not inherit from an abstract class, in that case it can have implementation for all of its methods. -Concrete classes are used to provide specific implementation details for a group of related classes that inherit from a common abstract class. They are also used to define unique behavior for a specific class. A concrete class can have its own methods and variables, and can also override the methods of its parent class. +Concrete classes are used to provide specific implementation details for a group of related classes that inherit from a common abstract class. They are also used to define unique behavior for a specific class. A concrete class can have its own methods and variables, and can also override the methods of its parent class. \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/coupling-and-cohesion@TXus3R5vVQDBeBag6B5qs.md b/src/data/roadmaps/software-design-architecture/content/coupling-and-cohesion@TXus3R5vVQDBeBag6B5qs.md index bc59c8e3a..862821392 100644 --- a/src/data/roadmaps/software-design-architecture/content/coupling-and-cohesion@TXus3R5vVQDBeBag6B5qs.md +++ b/src/data/roadmaps/software-design-architecture/content/coupling-and-cohesion@TXus3R5vVQDBeBag6B5qs.md @@ -6,6 +6,6 @@ Coupling refers to the degree to which one component depends on another componen Cohesion, on the other hand, refers to the degree to which the responsibilities of a component are related to each other. High cohesion means that a component has a single, well-defined purpose and that all its functionality and data is related to that purpose. Low cohesion, on the other hand, means that a component has multiple, unrelated responsibilities, making it more difficult to understand, test, and maintain. -To learn more, visit the following links: +Visit the following resources to learn more: -- [@video@Cohesion and Coupling in Software Engineering](https://www.youtube.com/watch?v=NweTzHYBgYU) +- [@video@Cohesion and Coupling in Software Engineering](https://www.youtube.com/watch?v=NweTzHYBgYU) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/cqrs@IU86cGkLPMXUJKvTBywPu.md b/src/data/roadmaps/software-design-architecture/content/cqrs@IU86cGkLPMXUJKvTBywPu.md index 7b495f97a..c9c92f8da 100644 --- a/src/data/roadmaps/software-design-architecture/content/cqrs@IU86cGkLPMXUJKvTBywPu.md +++ b/src/data/roadmaps/software-design-architecture/content/cqrs@IU86cGkLPMXUJKvTBywPu.md @@ -4,7 +4,7 @@ CQRS (Command Query Responsibility Segregation) is an architectural pattern that The command side is responsible for processing commands and updating the system's state, while the query side is responsible for reading the current state of the system and returning the results to the client. The command and query sides can use different data models, storage mechanisms, and even different technologies. -Learn more from the following resources: +Visit the following resources to learn more: - [@article@Get Started with CQRS Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs) -- [@article@CQRS Software Architecture Pattern: The Good, Bad, and the Ugly](https://betterprogramming.pub/cqrs-software-architecture-pattern-the-good-the-bad-and-the-ugly-e9d6e7a34daf) +- [@article@CQRS Software Architecture Pattern: The Good, Bad, and the Ugly](https://betterprogramming.pub/cqrs-software-architecture-pattern-the-good-the-bad-and-the-ugly-e9d6e7a34daf) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/design-patterns@Jd79KXxZavpnp3mtE1q0n.md b/src/data/roadmaps/software-design-architecture/content/design-patterns@Jd79KXxZavpnp3mtE1q0n.md index 81bf7722d..49c1d986a 100644 --- a/src/data/roadmaps/software-design-architecture/content/design-patterns@Jd79KXxZavpnp3mtE1q0n.md +++ b/src/data/roadmaps/software-design-architecture/content/design-patterns@Jd79KXxZavpnp3mtE1q0n.md @@ -4,14 +4,14 @@ Design patterns are general solutions to common problems that arise in software There are several different types of design patterns, including: -- Creational patterns -- Structural patterns -- Behavioral patterns -- Architectural patterns +* Creational patterns +* Structural patterns +* Behavioral patterns +* Architectural patterns -Learn more from the following links: +Visit the following resources to learn more: -- [@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) +- [@video@What Are Design Patterns?](https://www.youtube.com/watch?v=BWprw8UHIzA) +- [@feed@Explore top posts about Design Patterns](https://app.daily.dev/tags/design-patterns?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/design-patterns@gyQw885dvupmkohzJPg3a.md b/src/data/roadmaps/software-design-architecture/content/design-patterns@gyQw885dvupmkohzJPg3a.md index 81bf7722d..49c1d986a 100644 --- a/src/data/roadmaps/software-design-architecture/content/design-patterns@gyQw885dvupmkohzJPg3a.md +++ b/src/data/roadmaps/software-design-architecture/content/design-patterns@gyQw885dvupmkohzJPg3a.md @@ -4,14 +4,14 @@ Design patterns are general solutions to common problems that arise in software There are several different types of design patterns, including: -- Creational patterns -- Structural patterns -- Behavioral patterns -- Architectural patterns +* Creational patterns +* Structural patterns +* Behavioral patterns +* Architectural patterns -Learn more from the following links: +Visit the following resources to learn more: -- [@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) +- [@video@What Are Design Patterns?](https://www.youtube.com/watch?v=BWprw8UHIzA) +- [@feed@Explore top posts about Design Patterns](https://app.daily.dev/tags/design-patterns?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/design-principles@9dMbo4Q1_Sd9wW6-HSCA9.md b/src/data/roadmaps/software-design-architecture/content/design-principles@9dMbo4Q1_Sd9wW6-HSCA9.md index db89dc337..56609c2f9 100644 --- a/src/data/roadmaps/software-design-architecture/content/design-principles@9dMbo4Q1_Sd9wW6-HSCA9.md +++ b/src/data/roadmaps/software-design-architecture/content/design-principles@9dMbo4Q1_Sd9wW6-HSCA9.md @@ -1,2 +1 @@ -# Design Principles - +# Design Principles \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/design-principles@p96fNXv0Z4rEEXJR9hAYX.md b/src/data/roadmaps/software-design-architecture/content/design-principles@p96fNXv0Z4rEEXJR9hAYX.md index 9e92d85b9..76c03036e 100644 --- a/src/data/roadmaps/software-design-architecture/content/design-principles@p96fNXv0Z4rEEXJR9hAYX.md +++ b/src/data/roadmaps/software-design-architecture/content/design-principles@p96fNXv0Z4rEEXJR9hAYX.md @@ -1,3 +1,3 @@ # Design Principles -Design principles are fundamental guidelines that help software engineers create systems that are maintainable, scalable, robust, and easy to understand. They represent best practices derived from decades of software engineering experience and are widely used to guide the structure and behavior of code. Applying these principles can lead to better software architecture, easier debugging, and improved collaboration. +Design principles are fundamental guidelines that help software engineers create systems that are maintainable, scalable, robust, and easy to understand. They represent best practices derived from decades of software engineering experience and are widely used to guide the structure and behavior of code. Applying these principles can lead to better software architecture, easier debugging, and improved collaboration. \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/distributed@3V74lLPlcOXFB-QRTUA5j.md b/src/data/roadmaps/software-design-architecture/content/distributed@3V74lLPlcOXFB-QRTUA5j.md index 09dce456d..b159c20fd 100644 --- a/src/data/roadmaps/software-design-architecture/content/distributed@3V74lLPlcOXFB-QRTUA5j.md +++ b/src/data/roadmaps/software-design-architecture/content/distributed@3V74lLPlcOXFB-QRTUA5j.md @@ -2,6 +2,6 @@ Distributed systems refer to the design and organization of software components that are distributed across multiple devices or locations, connected via a network, and work together to achieve a common goal. The main challenge in designing distributed systems is dealing with the inherent complexity that arises from the distribution of components and the communication between them, and it requires techniques such as load balancing, replication, and partitioning to improve scalability, fault-tolerance, and performance. Additionally, security and coordination are also important aspects of distributed systems. -Learn more from the following links: +Visit the following resources to learn more: -- [@article@Overview of Distributed Architecture](https://www.tutorialspoint.com/software_architecture_design/distributed_architecture.htm) +- [@article@Overview of Distributed Architecture](https://www.tutorialspoint.com/software_architecture_design/distributed_architecture.htm) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/domain-driven-design@CD20zA6k9FxUpMgHnNYRJ.md b/src/data/roadmaps/software-design-architecture/content/domain-driven-design@CD20zA6k9FxUpMgHnNYRJ.md index 72cc91bf6..6f71d0874 100644 --- a/src/data/roadmaps/software-design-architecture/content/domain-driven-design@CD20zA6k9FxUpMgHnNYRJ.md +++ b/src/data/roadmaps/software-design-architecture/content/domain-driven-design@CD20zA6k9FxUpMgHnNYRJ.md @@ -2,10 +2,10 @@ Domain-Driven Design (DDD) is an architectural pattern that is used to design software systems based on the core business domain and business entities, it's focused on creating a clear and accurate representation of the business domain within the software system, and on aligning the software system with the business goals and objectives. DDD provides several advantages over other architectural patterns, such as alignment with business goals and objectives, improved communication between domain experts and developers, a clear and expressive model of the business domain and improved scalability and maintainability. It's implemented using a set of principles and patterns such as strategic design, subdomains, bounded context, entities, value objects, aggregate, and repository. -Learn more from the following links: +Visit the following resources to learn more: -- [@video@What is DDD (Domain-Driven Design) ?](https://www.youtube.com/watch?v=Tnecs_7OT74) -- [@video@Domain-Driven Design patterns for a distributed system](https://www.youtube.com/watch?v=i3d_jzpf0gE) - [@article@Modern Software Architecture (#1): Domain Driven Design](https://medium.com/modern-software-architecture/modern-software-architecture-1-domain-driven-design-f06fad8695f9) - [@article@The Concept of Domain-Driven Design Explained](https://medium.com/microtica/the-concept-of-domain-driven-design-explained-3184c0fd7c3f) -- [@feed@Explore top posts about Domain-Driven Design](https://app.daily.dev/tags/domain-driven-design?ref=roadmapsh) +- [@video@What is DDD (Domain-Driven Design) ?](https://www.youtube.com/watch?v=Tnecs_7OT74) +- [@video@Domain-Driven Design patterns for a distributed system](https://www.youtube.com/watch?v=i3d_jzpf0gE) +- [@feed@Explore top posts about Domain-Driven Design](https://app.daily.dev/tags/domain-driven-design?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/domain-language@kWNQd3paQrhMHMJzM35w8.md b/src/data/roadmaps/software-design-architecture/content/domain-language@kWNQd3paQrhMHMJzM35w8.md index 9ec7b52f8..7cecaadeb 100644 --- a/src/data/roadmaps/software-design-architecture/content/domain-language@kWNQd3paQrhMHMJzM35w8.md +++ b/src/data/roadmaps/software-design-architecture/content/domain-language@kWNQd3paQrhMHMJzM35w8.md @@ -4,7 +4,7 @@ A domain language is a specific vocabulary and set of concepts used to describe A domain language is used to provide a common understanding of the problem domain among all stakeholders, including developers, business analysts, and domain experts. It is also used to ensure that the software system accurately reflects the real-world problem it is intended to solve. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Overview of Domain-specific language](https://en.wikipedia.org/wiki/Domain-specific_language) -- [@article@What are Domain Languages (DSLs)?](https://www.jetbrains.com/mps/concepts/domain-specific-languages/) +- [@article@What are Domain Languages (DSLs)?](https://www.jetbrains.com/mps/concepts/domain-specific-languages/) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/domain-models@I25ghe8xYWpZ-9pRcHfOh.md b/src/data/roadmaps/software-design-architecture/content/domain-models@I25ghe8xYWpZ-9pRcHfOh.md index 3a672ecd4..d7be7381e 100644 --- a/src/data/roadmaps/software-design-architecture/content/domain-models@I25ghe8xYWpZ-9pRcHfOh.md +++ b/src/data/roadmaps/software-design-architecture/content/domain-models@I25ghe8xYWpZ-9pRcHfOh.md @@ -4,7 +4,7 @@ A domain model is a representation of a specific area of knowledge or business t A domain model is used to provide a clear and consistent representation of the problem domain, and to capture the business requirements and constraints of the system. It is also used to guide the design of the system and to ensure that the system accurately reflects the real-world problem it is intended to solve. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Overview of Domain model](https://en.wikipedia.org/wiki/Domain_model) -- [@article@Domain Driven Design](https://khalilstemmler.com/articles/categories/domain-driven-design/) +- [@article@Domain Driven Design](https://khalilstemmler.com/articles/categories/domain-driven-design/) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/domain-models@NpSfbzYtGebmfrifkKsUf.md b/src/data/roadmaps/software-design-architecture/content/domain-models@NpSfbzYtGebmfrifkKsUf.md index 8e098b7cb..fe4eb11df 100644 --- a/src/data/roadmaps/software-design-architecture/content/domain-models@NpSfbzYtGebmfrifkKsUf.md +++ b/src/data/roadmaps/software-design-architecture/content/domain-models@NpSfbzYtGebmfrifkKsUf.md @@ -4,7 +4,7 @@ Domain Models are a pattern used in enterprise application development to repres A Domain Model is a collection of objects that represent the real-world concepts and entities of the domain. These objects are typically modeled as classes or types, and they encapsulate the data and behavior that is specific to the domain. They are responsible for representing the state and behavior of the business concepts they model, and for enforcing the rules and constraints of the domain. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Overview - Domain Models](https://sparxsystems.com/enterprise_architect_user_guide/14.0/model_domains/specialized_models.html) -- [@video@Tutorial - Domain Model Pattern](https://www.youtube.com/watch?v=75EGANiqADw) +- [@video@Tutorial - Domain Model Pattern](https://www.youtube.com/watch?v=75EGANiqADw) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/dry@ltBnVWZ3UMAuUvDkU6o4P.md b/src/data/roadmaps/software-design-architecture/content/dry@ltBnVWZ3UMAuUvDkU6o4P.md index e451851ed..053946529 100644 --- a/src/data/roadmaps/software-design-architecture/content/dry@ltBnVWZ3UMAuUvDkU6o4P.md +++ b/src/data/roadmaps/software-design-architecture/content/dry@ltBnVWZ3UMAuUvDkU6o4P.md @@ -4,7 +4,7 @@ DRY (Don't Repeat Yourself) is a software development principle that suggests th The DRY principle is closely related to the Single Responsibility Principle (SRP) and the Open-Closed Principle (OCP), which are part of the SOLID principles. The DRY principle aims to reduce the amount of duplicate code by creating abstractions that can be reused across the system. -Learn more from the following resources: +Visit the following resources to learn more: -- [@video@What is DRY in programming?](https://www.youtube.com/watch?v=Rv3RIc_ziOY) - [@article@Overview of Don't repeat yourself (DRY)](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) +- [@video@What is DRY in programming?](https://www.youtube.com/watch?v=Rv3RIc_ziOY) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/dtos@y_Qj7KITSB8aUWHwiZ2It.md b/src/data/roadmaps/software-design-architecture/content/dtos@y_Qj7KITSB8aUWHwiZ2It.md index 48fe1cecd..aa14bad62 100644 --- a/src/data/roadmaps/software-design-architecture/content/dtos@y_Qj7KITSB8aUWHwiZ2It.md +++ b/src/data/roadmaps/software-design-architecture/content/dtos@y_Qj7KITSB8aUWHwiZ2It.md @@ -2,6 +2,6 @@ The Data Transfer Object Design Pattern is one of the enterprise application architecture patterns that calls for the use of objects that aggregate and encapsulate data for transfer. A Data Transfer Object is, essentially, like a data structure. It should not contain any business logic but should contain serialization and deserialization mechanisms. -Learn more from the following links: +Visit the following resources to learn more: -- [@article@Data Transfer Object pattern and Mappers](https://medium.com/@abdalrhmanalkraien/data-transfer-object-pattern-and-mapper-116508bc9df0) +- [@article@Data Transfer Object pattern and Mappers](https://medium.com/@abdalrhmanalkraien/data-transfer-object-pattern-and-mapper-116508bc9df0) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/encapsulate-what-varies@DlefJ9JuJ1LdQYC4WSx6y.md b/src/data/roadmaps/software-design-architecture/content/encapsulate-what-varies@DlefJ9JuJ1LdQYC4WSx6y.md index 056925941..2962446ff 100644 --- a/src/data/roadmaps/software-design-architecture/content/encapsulate-what-varies@DlefJ9JuJ1LdQYC4WSx6y.md +++ b/src/data/roadmaps/software-design-architecture/content/encapsulate-what-varies@DlefJ9JuJ1LdQYC4WSx6y.md @@ -4,7 +4,7 @@ Encapsulate what varies is a programming principle that suggests that code shoul Encapsulating what varies allows for more flexibility in the code. When changes are needed, they can be made to the encapsulated parts without affecting the rest of the code. This makes it easier to understand, test, and maintain the code. -Learn more from the following resources: +Visit the following resources to learn more: - [@article@What does it mean when one says “Encapsulate what varies”?](https://softwareengineering.stackexchange.com/questions/337413/what-does-it-mean-when-one-says-encapsulate-what-varies) -- [@article@Overview of Encapsulate What Varies](https://bootcamp.uxdesign.cc/software-design-principles-every-developers-should-know-23d24735518e) +- [@article@Overview of Encapsulate What Varies](https://bootcamp.uxdesign.cc/software-design-principles-every-developers-should-know-23d24735518e) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/encapsulation@GJxfVjhiLuuc36hatx9dP.md b/src/data/roadmaps/software-design-architecture/content/encapsulation@GJxfVjhiLuuc36hatx9dP.md index b0e331af7..637beaa56 100644 --- a/src/data/roadmaps/software-design-architecture/content/encapsulation@GJxfVjhiLuuc36hatx9dP.md +++ b/src/data/roadmaps/software-design-architecture/content/encapsulation@GJxfVjhiLuuc36hatx9dP.md @@ -4,8 +4,8 @@ Encapsulation is a concept in object-oriented programming (OOP) that refers to t Encapsulation is achieved by using access modifiers (such as "public," "private," and "protected") to control the visibility and accessibility of an object's data and methods. For example, data members of a class can be declared as private, which means they can only be accessed by methods within the class, while methods can be declared as public, which means they can be called by any code that has a reference to the object. -Learn more from the following links: +Visit the following resources to learn more: -- [@article@Overview of Encapsulation](https://en.wikipedia.org/wiki/Encapsulation_\(computer_programming\)) +- [@article@Overview of Encapsulation](https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)) - [@video@Tutorial - What is encapsulation in programming?](https://www.youtube.com/watch?v=sNKKxc4QHqA) -- [@feed@Explore top posts about General Programming](https://app.daily.dev/tags/general-programming?ref=roadmapsh) +- [@feed@Explore top posts about General Programming](https://app.daily.dev/tags/general-programming?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/enterprise-patterns@WrzsvLgo7cf2KjvJhtJEC.md b/src/data/roadmaps/software-design-architecture/content/enterprise-patterns@WrzsvLgo7cf2KjvJhtJEC.md index 8a9f46baa..712d13aec 100644 --- a/src/data/roadmaps/software-design-architecture/content/enterprise-patterns@WrzsvLgo7cf2KjvJhtJEC.md +++ b/src/data/roadmaps/software-design-architecture/content/enterprise-patterns@WrzsvLgo7cf2KjvJhtJEC.md @@ -2,18 +2,18 @@ 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) +* 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: +Visit the following resources to learn more: - [@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) +- [@feed@Explore top posts about Enterprise](https://app.daily.dev/tags/enterprise?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/enterprise-patterns@h0aeBhQRkDxNeFwDxT4Tf.md b/src/data/roadmaps/software-design-architecture/content/enterprise-patterns@h0aeBhQRkDxNeFwDxT4Tf.md index 8a9f46baa..712d13aec 100644 --- a/src/data/roadmaps/software-design-architecture/content/enterprise-patterns@h0aeBhQRkDxNeFwDxT4Tf.md +++ b/src/data/roadmaps/software-design-architecture/content/enterprise-patterns@h0aeBhQRkDxNeFwDxT4Tf.md @@ -2,18 +2,18 @@ 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) +* 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: +Visit the following resources to learn more: - [@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) +- [@feed@Explore top posts about Enterprise](https://app.daily.dev/tags/enterprise?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/entities@VnW_7dl5G0IFL9W3YF_W3.md b/src/data/roadmaps/software-design-architecture/content/entities@VnW_7dl5G0IFL9W3YF_W3.md index c9c9666a3..0689dba2c 100644 --- a/src/data/roadmaps/software-design-architecture/content/entities@VnW_7dl5G0IFL9W3YF_W3.md +++ b/src/data/roadmaps/software-design-architecture/content/entities@VnW_7dl5G0IFL9W3YF_W3.md @@ -2,4 +2,4 @@ Entities are a pattern used in enterprise application development to represent the business concepts that have a unique identity and a lifetime. They are typically used to model real-world objects or concepts that have a distinct identity and a lifecycle, such as a customer, an order, or an account. -An Entity is defined by its identity, meaning that two entities with the same identity are considered to be the same, regardless of their state. Entities usually have a unique identifier, such as a primary key, that is used to identify them. They also have an associated set of properties or attributes that describe their state. +An Entity is defined by its identity, meaning that two entities with the same identity are considered to be the same, regardless of their state. Entities usually have a unique identifier, such as a primary key, that is used to identify them. They also have an associated set of properties or attributes that describe their state. \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/event-driven@KtzcJBb6-EcIoXnwYvE7a.md b/src/data/roadmaps/software-design-architecture/content/event-driven@KtzcJBb6-EcIoXnwYvE7a.md index 91d371a94..b79309294 100644 --- a/src/data/roadmaps/software-design-architecture/content/event-driven@KtzcJBb6-EcIoXnwYvE7a.md +++ b/src/data/roadmaps/software-design-architecture/content/event-driven@KtzcJBb6-EcIoXnwYvE7a.md @@ -4,7 +4,7 @@ Event-driven architecture (EDA) is a software design pattern in which the system The main advantage of using EDA is that it allows for a clear separation of concerns between the components, and it can improve the scalability and fault-tolerance of the system. Additionally, it allows for loose coupling between components, meaning that the components are not aware of each other's existence, and can be developed, deployed, and scaled independently. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Overview of Event-driven programming](https://en.wikipedia.org/wiki/Event-driven_programming) -- [@article@What is event-driven architecture?](https://www.redhat.com/en/topics/integration/what-is-event-driven-architecture) +- [@article@What is event-driven architecture?](https://www.redhat.com/en/topics/integration/what-is-event-driven-architecture) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/event-sourcing@K8X_-bsiy7gboInPzbiEb.md b/src/data/roadmaps/software-design-architecture/content/event-sourcing@K8X_-bsiy7gboInPzbiEb.md index e91e134fe..80fcbdb38 100644 --- a/src/data/roadmaps/software-design-architecture/content/event-sourcing@K8X_-bsiy7gboInPzbiEb.md +++ b/src/data/roadmaps/software-design-architecture/content/event-sourcing@K8X_-bsiy7gboInPzbiEb.md @@ -4,8 +4,8 @@ Event sourcing is an architectural pattern that is used to build systems that ne In Event sourcing, all changes to the state of the system are treated as events, and these events are stored in an append-only log, also known as an event store. The current state of the system can be reconstructed from the event log at any given point in time by replaying the events from the log. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Event Sourcing Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing) - [@video@Event Sourcing Example & Explained](https://www.youtube.com/watch?v=AUj4M-st3ic&list=PLThyvG1mlMzkRKJnhzvxtSAbY8oxENLUQ&ab_channel=CodeOpinion) -- [@feed@Explore top posts about Architecture](https://app.daily.dev/tags/architecture?ref=roadmapsh) +- [@feed@Explore top posts about Architecture](https://app.daily.dev/tags/architecture?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/functional-programming@YswaOqZNYcmDwly2IXrTT.md b/src/data/roadmaps/software-design-architecture/content/functional-programming@YswaOqZNYcmDwly2IXrTT.md index 8f631da8b..85044be62 100644 --- a/src/data/roadmaps/software-design-architecture/content/functional-programming@YswaOqZNYcmDwly2IXrTT.md +++ b/src/data/roadmaps/software-design-architecture/content/functional-programming@YswaOqZNYcmDwly2IXrTT.md @@ -2,7 +2,7 @@ Functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It emphasizes the use of functions to solve problems, often using higher-order functions, immutability, and recursion. Instead of modifying data, functional programming creates new data structures. -Learn more from the following links: +Visit the following resources to learn more: - [@article@What is Functional Programming?](https://medium.com/javascript-scene/master-the-javascript-interview-what-is-functional-programming-7f218c68b3a0) -- [@feed@Explore top posts about Functional Programming](https://app.daily.dev/tags/functional-programming?ref=roadmapsh) +- [@feed@Explore top posts about Functional Programming](https://app.daily.dev/tags/functional-programming?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/gof-design-patterns@hlHl00ELlK9YdnzHDGnEW.md b/src/data/roadmaps/software-design-architecture/content/gof-design-patterns@hlHl00ELlK9YdnzHDGnEW.md index c38a3eefc..a2f3eae58 100644 --- a/src/data/roadmaps/software-design-architecture/content/gof-design-patterns@hlHl00ELlK9YdnzHDGnEW.md +++ b/src/data/roadmaps/software-design-architecture/content/gof-design-patterns@hlHl00ELlK9YdnzHDGnEW.md @@ -4,11 +4,11 @@ The Gang of Four (GoF) design patterns are a set of design patterns for object-o The GoF design patterns are divided into three categories: Creational, Structural and Behavioral. -- Creational Patterns -- Structural Patterns -- Behavioral Patterns +* Creational Patterns +* Structural Patterns +* Behavioral Patterns -Learn more from the following links: +Visit the following resources to learn more: - [@article@Gangs of Four (GoF) Design Patterns](https://www.digitalocean.com/community/tutorials/gangs-of-four-gof-design-patterns) -- [@video@Tutorial - Builder Pattern (Gang of Four Design Patterns Series)](https://www.youtube.com/watch?v=_sa2WlAFWQos) +- [@video@Tutorial - Builder Pattern (Gang of Four Design Patterns Series)](https://www.youtube.com/watch?v=_sa2WlAFWQos) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/hollywood-principle@WzUhKlmFB9alTlAyV-MWJ.md b/src/data/roadmaps/software-design-architecture/content/hollywood-principle@WzUhKlmFB9alTlAyV-MWJ.md index 50e538c33..f5fd7d8eb 100644 --- a/src/data/roadmaps/software-design-architecture/content/hollywood-principle@WzUhKlmFB9alTlAyV-MWJ.md +++ b/src/data/roadmaps/software-design-architecture/content/hollywood-principle@WzUhKlmFB9alTlAyV-MWJ.md @@ -4,6 +4,6 @@ The Hollywood Principle is a software development principle that states: "Don't This principle is often used in the context of inversion of control (IoC) and dependency injection. In traditional software development, low-level components are responsible for creating and managing the high-level components that they depend on. With IoC, the high-level components dictate the flow of control, and the low-level components are created and managed by a separate mechanism. -Learn more from the following resources: +Visit the following resources to learn more: -- [@video@Tutorial - Hollywood Principle](https://www.youtube.com/watch?v=lRuygpsXE5s) +- [@video@Tutorial - Hollywood Principle](https://www.youtube.com/watch?v=lRuygpsXE5s) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/identity-maps@tb0X1HtuiGwz7YhQ5xPsV.md b/src/data/roadmaps/software-design-architecture/content/identity-maps@tb0X1HtuiGwz7YhQ5xPsV.md index 16202c927..37c50335a 100644 --- a/src/data/roadmaps/software-design-architecture/content/identity-maps@tb0X1HtuiGwz7YhQ5xPsV.md +++ b/src/data/roadmaps/software-design-architecture/content/identity-maps@tb0X1HtuiGwz7YhQ5xPsV.md @@ -4,7 +4,7 @@ Identity Maps is a pattern used in enterprise application development to maintai The identity map pattern is typically used in conjunction with an ORM (Object-Relational Mapping) tool. When an object is loaded from the database, it is first checked against the identity map to see if it has already been loaded. If it has, the existing object is returned, instead of creating a new copy. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Overview of Identity map pattern](https://en.wikipedia.org/wiki/Identity_map_pattern) -- [@video@Tutorial - Identity Map Design Pattern](https://youtube.com/watch?v=erDxkIyNudY) +- [@video@Tutorial - Identity Map Design Pattern](https://youtube.com/watch?v=erDxkIyNudY) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/indentation-and-code-style@81WOL1nxb56ZbAOvxJ7NK.md b/src/data/roadmaps/software-design-architecture/content/indentation-and-code-style@81WOL1nxb56ZbAOvxJ7NK.md index fd3c8aab2..700c64eee 100644 --- a/src/data/roadmaps/software-design-architecture/content/indentation-and-code-style@81WOL1nxb56ZbAOvxJ7NK.md +++ b/src/data/roadmaps/software-design-architecture/content/indentation-and-code-style@81WOL1nxb56ZbAOvxJ7NK.md @@ -4,7 +4,7 @@ Indentation is the practice of using whitespace to visually group related lines Having a consistent indentation and code style can help to make the code more readable and understandable, which can improve the maintainability of the system. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Clean Code – Formatting](https://www.baeldung.com/cs/clean-code-formatting) -- [@feed@Explore top posts about General Programming](https://app.daily.dev/tags/general-programming?ref=roadmapsh) +- [@feed@Explore top posts about General Programming](https://app.daily.dev/tags/general-programming?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/inheritance@Dj36yLBShoazj7SAw6a_A.md b/src/data/roadmaps/software-design-architecture/content/inheritance@Dj36yLBShoazj7SAw6a_A.md index c18451e1e..de0d8d21a 100644 --- a/src/data/roadmaps/software-design-architecture/content/inheritance@Dj36yLBShoazj7SAw6a_A.md +++ b/src/data/roadmaps/software-design-architecture/content/inheritance@Dj36yLBShoazj7SAw6a_A.md @@ -2,7 +2,7 @@ Inheritance is a fundamental concept in object-oriented programming (OOP) that allows a new class to inherit the properties and methods of an existing class. The class that is inherited from is called the parent or super class, while the class that inherits is called the child or sub class. Inheritance enables code reuse and allows for a hierarchical organization of classes, where a child class can inherit the properties and methods of its parent class and potentially add or override them. The main advantage of inheritance is that it allows for a clean and organized way to reuse code and share functionality among classes. -Learn more from the following links: +Visit the following resources to learn more: -- [@video@What is inheritance in programming?](https://www.youtube.com/watch?v=ajOYOxCanhE) - [@article@Overview of Inheritance (object-oriented programming)](https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)) +- [@video@What is inheritance in programming?](https://www.youtube.com/watch?v=ajOYOxCanhE) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/interfaces@SrcPhS4F7aT80qNjbv54f.md b/src/data/roadmaps/software-design-architecture/content/interfaces@SrcPhS4F7aT80qNjbv54f.md index f37402cc0..6c37d617d 100644 --- a/src/data/roadmaps/software-design-architecture/content/interfaces@SrcPhS4F7aT80qNjbv54f.md +++ b/src/data/roadmaps/software-design-architecture/content/interfaces@SrcPhS4F7aT80qNjbv54f.md @@ -4,6 +4,6 @@ In object-oriented programming (OOP), an interface is a contract or a set of met Interfaces are used to define a common behavior for a group of related classes, and to provide a way for objects of different classes to be treated polymorphically. A class that implements an interface must provide an implementation for all of the methods declared in the interface. A class can implement multiple interfaces, but can only inherit from one base class. -Learn more from the following resources: +Visit the following resources to learn more: -- [@video@Fundamental concepts: What's an Interface?](https://www.youtube.com/watch?v=o1jBgdhQsGo) +- [@video@Fundamental concepts: What's an Interface?](https://www.youtube.com/watch?v=o1jBgdhQsGo) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/keep-framework-code-distant@OoCCy-3W5y7bUcKz_iyBw.md b/src/data/roadmaps/software-design-architecture/content/keep-framework-code-distant@OoCCy-3W5y7bUcKz_iyBw.md index a84d264f6..707176ff0 100644 --- a/src/data/roadmaps/software-design-architecture/content/keep-framework-code-distant@OoCCy-3W5y7bUcKz_iyBw.md +++ b/src/data/roadmaps/software-design-architecture/content/keep-framework-code-distant@OoCCy-3W5y7bUcKz_iyBw.md @@ -4,15 +4,15 @@ Keeping framework code distant refers to separating the application's code from 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. +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: +Visit the following resources to learn more: - [@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) +- [@feed@Explore top posts about General Programming](https://app.daily.dev/tags/general-programming?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/keep-it-simple-and-refactor-often@9naCfoHF1LW1OEsVZGi8v.md b/src/data/roadmaps/software-design-architecture/content/keep-it-simple-and-refactor-often@9naCfoHF1LW1OEsVZGi8v.md index 25ce24327..d0acfe4f1 100644 --- a/src/data/roadmaps/software-design-architecture/content/keep-it-simple-and-refactor-often@9naCfoHF1LW1OEsVZGi8v.md +++ b/src/data/roadmaps/software-design-architecture/content/keep-it-simple-and-refactor-often@9naCfoHF1LW1OEsVZGi8v.md @@ -1,22 +1,17 @@ -# Keep It Simple and Refactor Often +# Avoid Hasty Abstractions -Keeping code simple and refactoring often is a core engineering discipline that helps prevent technical debt and keeps systems healthy over time. Simplicity reduces bugs, while frequent refactoring ensures the code evolves alongside changing requirements. +Creating abstractions is an important part of software development, but creating too many abstractions or creating them too early can lead to unnecessary complexity and make the code harder to understand and maintain. -Key principles of this practice include: +Here are some ways to avoid hasty abstractions in system architecture: -* Simplicity first: Write the simplest code that solves the problem today. -* Avoid over-engineering: Do not design for hypothetical future requirements. -* Small steps: Make incremental improvements instead of large, risky rewrites. -* Continuous refactoring: Improve code structure whenever you add or modify functionality. -* Readability over cleverness: Prefer clear, straightforward solutions. -* Remove duplication: Consolidate repeated logic into reusable components. -* Improve naming: Refactoring includes renaming variables, functions, and classes for clarity. -* Maintain behavior: Refactoring should not change what the code does, only how it’s structured. -* Feedback-driven: Use tests, code reviews, and metrics to guide refactoring efforts. -* Long-term productivity: Clean, simple code is faster to work with over time. +* Understand the problem that needs to be solved before creating an abstraction. +* Start with a simple solution and only create an abstraction when it becomes clear that the solution is becoming too complex. +* Use code refactoring techniques to simplify the code before creating an abstraction. +* Avoid creating abstractions for the sake of creating abstractions. +* Use established design patterns and practices when creating abstractions, but do not force them into the code. +* Use automated testing to ensure that the abstraction does not introduce new bugs or break existing functionality. +* Create abstraction in a way that it's easy to test, debug, and reason about. -Learn more from the following links: +Visit the following resources to learn more: -* [@article@Refactoring: Improving the Design of Existing Code](https://martinfowler.com/books/refactoring.html) -* [@article@KISS Principle in Software Development](https://www.geeksforgeeks.org/kiss-principle-in-software-development/) -* [@feed@Explore top posts about Clean Code](https://app.daily.dev/tags/clean-code?ref=roadmapsh) +- [@article@AHA Programming](https://kentcdodds.com/blog/aha-programming) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/keep-methods--classes--files-small@XEwC6Fyf2DNNHQsoGTrQj.md b/src/data/roadmaps/software-design-architecture/content/keep-methods--classes--files-small@XEwC6Fyf2DNNHQsoGTrQj.md index cd31a98c3..d2394f3a5 100644 --- a/src/data/roadmaps/software-design-architecture/content/keep-methods--classes--files-small@XEwC6Fyf2DNNHQsoGTrQj.md +++ b/src/data/roadmaps/software-design-architecture/content/keep-methods--classes--files-small@XEwC6Fyf2DNNHQsoGTrQj.md @@ -1,3 +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. +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. \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/law-of-demeter@vnLhItObDgp_XaDmplBsJ.md b/src/data/roadmaps/software-design-architecture/content/law-of-demeter@vnLhItObDgp_XaDmplBsJ.md index c30421714..810475906 100644 --- a/src/data/roadmaps/software-design-architecture/content/law-of-demeter@vnLhItObDgp_XaDmplBsJ.md +++ b/src/data/roadmaps/software-design-architecture/content/law-of-demeter@vnLhItObDgp_XaDmplBsJ.md @@ -2,33 +2,34 @@ Also called “Principle of Least Knowledge”, it states: -A method should only interact with its immediate dependencies, not deeply nested objects. +In Practice +----------- -## In Practice - -- Avoid chaining calls deep into the internals of other objects. -- Restrict communication to objects you directly manage. +* Avoid chaining calls deep into the internals of other objects. +* Restrict communication to objects you directly manage. ### 🔹 ❌ Bad Example (Violation) -``` -// Controller -total = order.customer.address.getRegionTaxRate() * order.amount -``` + // Controller + total = order.customer.address.getRegionTaxRate() * order.amount + -### 🔹 ✅ Good Example +### 🔹 ✅ Good Example -``` -// Controller -total = order.calculateTotal() -``` + // Controller + total = order.calculateTotal() + -## 🔹 Why It Matters +🔹 Why It Matters +----------------- -- **Reduces coupling** → fewer dependencies between classes. -- **Increases maintainability** → changes in one class don’t affect distant classes. -- **Improves readability** → clear boundaries of responsibility. +* **Reduces coupling** → fewer dependencies between classes. +* **Increases maintainability** → changes in one class don’t affect distant classes. +* **Improves readability** → clear boundaries of responsibility. -## 🔹 Resources +🔹 Resources +------------ -- [@Article: Law of Demeter Explained](https://en.wikipedia.org/wiki/Law_of_Demeter) +Visit the following resources to learn more: + +- [@article@@Article: Law of Demeter Explained](https://en.wikipedia.org/wiki/Law_of_Demeter) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/layered-architectures@HN160YgryBBtVGjnWxNie.md b/src/data/roadmaps/software-design-architecture/content/layered-architectures@HN160YgryBBtVGjnWxNie.md index 59483bb6e..e741aeb0b 100644 --- a/src/data/roadmaps/software-design-architecture/content/layered-architectures@HN160YgryBBtVGjnWxNie.md +++ b/src/data/roadmaps/software-design-architecture/content/layered-architectures@HN160YgryBBtVGjnWxNie.md @@ -4,12 +4,12 @@ A layered architecture is a software design pattern in which the functionality o There are several types of layered architectures, but a common one is the three-layer architecture which consists of: -- Presentation Layer -- Business Layer -- Data Access Layer +* Presentation Layer +* Business Layer +* Data Access Layer -Learn more from the following links: +Visit the following resources to learn more: - [@article@Software Architecture Patterns — Layered Architecture](https://priyalwalpita.medium.com/software-architecture-patterns-layered-architecture-a3b89b71a057) - [@article@5 Primary Layers in Software Architecture?](https://www.indeed.com/career-advice/career-development/what-are-the-layers-in-software-architecture) -- [@feed@Explore top posts about Architecture](https://app.daily.dev/tags/architecture?ref=roadmapsh) +- [@feed@Explore top posts about Architecture](https://app.daily.dev/tags/architecture?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/layered@IELEJcKYdZ6VN-UIq-Wln.md b/src/data/roadmaps/software-design-architecture/content/layered@IELEJcKYdZ6VN-UIq-Wln.md index eeba37c6c..b4b9c766f 100644 --- a/src/data/roadmaps/software-design-architecture/content/layered@IELEJcKYdZ6VN-UIq-Wln.md +++ b/src/data/roadmaps/software-design-architecture/content/layered@IELEJcKYdZ6VN-UIq-Wln.md @@ -4,7 +4,7 @@ In software architecture, layered architecture is a design approach in which a s A layered architecture is often used for large and complex systems, where the need for scalability and flexibility is high. Each layer in a layered architecture is responsible for a specific functionality and can be thought of as a "black box" with a well-defined interface. The layers communicate with each other through these interfaces, allowing for a clear separation of concerns. -Learn more from the following links: +Visit the following resources to learn more: -- [@video@Layered Architectures](https://www.youtube.com/watch?v=0kpTKLTx8f4) - [@article@Get started with Layered Architecture](https://cs.uwaterloo.ca/~m2nagapp/courses/CS446/1195/Arch_Design_Activity/Layered.pdf) +- [@video@Layered Architectures](https://www.youtube.com/watch?v=0kpTKLTx8f4) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/mappers@ndUTgl2YBzOdu1MQKJocu.md b/src/data/roadmaps/software-design-architecture/content/mappers@ndUTgl2YBzOdu1MQKJocu.md index 558e916ba..2e9fa91c5 100644 --- a/src/data/roadmaps/software-design-architecture/content/mappers@ndUTgl2YBzOdu1MQKJocu.md +++ b/src/data/roadmaps/software-design-architecture/content/mappers@ndUTgl2YBzOdu1MQKJocu.md @@ -4,7 +4,7 @@ Mappers are a pattern used in enterprise application development to provide a co A mapper is a component that can be used to convert data from one format or model to another. For example, a mapper can be used to convert data from a database model to a domain model, or from a domain model to a data transfer object (DTO). -Learn more from the following links: +Visit the following resources to learn more: - [@article@Overview of Data Mapper Pattern](https://en.wikipedia.org/wiki/Data_mapper_pattern) -- [@video@Tutorial - Mappers](https://www.youtube.com/watch?v=7noMLStHcTE) +- [@video@Tutorial - Mappers](https://www.youtube.com/watch?v=7noMLStHcTE) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/meaningful-names-over-comments@6Cd1BbGsmPJs_5jKhumyV.md b/src/data/roadmaps/software-design-architecture/content/meaningful-names-over-comments@6Cd1BbGsmPJs_5jKhumyV.md index 2519a8150..a89e07cab 100644 --- a/src/data/roadmaps/software-design-architecture/content/meaningful-names-over-comments@6Cd1BbGsmPJs_5jKhumyV.md +++ b/src/data/roadmaps/software-design-architecture/content/meaningful-names-over-comments@6Cd1BbGsmPJs_5jKhumyV.md @@ -2,6 +2,6 @@ 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: +Visit the following resources to learn more: -- [@article@A Guide for Naming Things in Programming](https://levelup.gitconnected.com/a-guide-for-naming-things-in-programming-2dc2d74879f8) +- [@article@A Guide for Naming Things in Programming](https://levelup.gitconnected.com/a-guide-for-naming-things-in-programming-2dc2d74879f8) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/message-queues--streams@GAs6NHBkUgxan3hyPvVs7.md b/src/data/roadmaps/software-design-architecture/content/message-queues--streams@GAs6NHBkUgxan3hyPvVs7.md index e6b667360..346de5083 100644 --- a/src/data/roadmaps/software-design-architecture/content/message-queues--streams@GAs6NHBkUgxan3hyPvVs7.md +++ b/src/data/roadmaps/software-design-architecture/content/message-queues--streams@GAs6NHBkUgxan3hyPvVs7.md @@ -4,7 +4,7 @@ Message queues and streams are architectural patterns that are used to decouple 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: +Visit the following resources to learn more: - [@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) +- [@article@Overview of Message Queue pattern](https://badia-kharroubi.gitbooks.io/microservices-architecture/content/patterns/communication-patterns/message-queue-pattern.html) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/messaging@j9j45Auf60kIskyEMUGE3.md b/src/data/roadmaps/software-design-architecture/content/messaging@j9j45Auf60kIskyEMUGE3.md index 0d3b72b4d..38a2e2f36 100644 --- a/src/data/roadmaps/software-design-architecture/content/messaging@j9j45Auf60kIskyEMUGE3.md +++ b/src/data/roadmaps/software-design-architecture/content/messaging@j9j45Auf60kIskyEMUGE3.md @@ -2,13 +2,13 @@ Messaging is a key concept in several architectural styles, including event-driven architecture (EDA), microservices, and message-driven architecture (MDA). -- Event-driven architecture (EDA) -- Microservices -- Message-driven architecture (MDA) +* Event-driven architecture (EDA) +* Microservices +* Message-driven architecture (MDA) In general, messaging is a powerful concept that allows for the decoupling and scalability of systems and it's used in different architectural styles to improve the flexibility and scalability of the system by allowing for loose coupling between components and making it easier to add new features or modify existing ones. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Architectural Styles in Software Engineering](https://shapingsoftware.com/2009/02/09/architectural-styles/) -- [@article@Architectural Messaging Patterns](https://www.redhat.com/architect/architectural-messaging-patterns) +- [@article@Architectural Messaging Patterns](https://www.redhat.com/architect/architectural-messaging-patterns) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/microkernel@r-Yeca-gpdFM8iq7f0lYQ.md b/src/data/roadmaps/software-design-architecture/content/microkernel@r-Yeca-gpdFM8iq7f0lYQ.md index 974e845fc..6c68986ae 100644 --- a/src/data/roadmaps/software-design-architecture/content/microkernel@r-Yeca-gpdFM8iq7f0lYQ.md +++ b/src/data/roadmaps/software-design-architecture/content/microkernel@r-Yeca-gpdFM8iq7f0lYQ.md @@ -2,7 +2,7 @@ A microkernel is an architectural pattern in operating system design that aims to minimize the amount of code running in kernel mode (i.e., privileged mode with direct access to hardware resources) and instead move as much functionality as possible into user mode. This is done by providing a small, minimalistic core kernel that only handles basic tasks such as memory management, process scheduling, and inter-process communication (IPC), and leaving all other functionality to be implemented in user-mode processes. -Learn more from the following links: +Visit the following resources to learn more: -- [@video@Microkernel Architectural Pattern | Software Architecture](https://www.youtube.com/watch?v=h3icQDMRLd8) - [@article@Overview of Microkernel Architecture](https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch03.html) +- [@video@Microkernel Architectural Pattern | Software Architecture](https://www.youtube.com/watch?v=h3icQDMRLd8) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/microservices@eJsCCURZAURCKnOK-XeQe.md b/src/data/roadmaps/software-design-architecture/content/microservices@eJsCCURZAURCKnOK-XeQe.md index 2fde82e31..b7de62f84 100644 --- a/src/data/roadmaps/software-design-architecture/content/microservices@eJsCCURZAURCKnOK-XeQe.md +++ b/src/data/roadmaps/software-design-architecture/content/microservices@eJsCCURZAURCKnOK-XeQe.md @@ -2,9 +2,9 @@ Microservices is an architectural pattern that is used to design software systems as a collection of small, independent, and loosely-coupled services. Each service is responsible for a specific functionality and can be developed, deployed, and scaled independently. The main advantage of a microservices architecture is that it allows for a more flexible and scalable system, it also improves fault isolation and enables faster deployment. It's often used in combination with other architectural patterns and styles such as event-driven architecture, CQRS, and service-oriented architecture. -Learn more from the following links: +Visit the following resources to learn more: +- [@official@Brief of Microservices](https://microservices.io/patterns/microservices.html) - [@video@Tutorial - Microservices Architectural Pattern](https://www.youtube.com/watch?v=8BPDv038oMI) - [@video@Get started with Microservices Design Patterns](https://www.youtube.com/watch?v=xuH81XGWeGQ) -- [@official@Brief of Microservices](https://microservices.io/patterns/microservices.html) -- [@feed@Explore top posts about Microservices](https://app.daily.dev/tags/microservices?ref=roadmapsh) +- [@feed@Explore top posts about Microservices](https://app.daily.dev/tags/microservices?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/minimize-cyclomatic-complexity@qZzl0hAD2LkShsPql1IlZ.md b/src/data/roadmaps/software-design-architecture/content/minimize-cyclomatic-complexity@qZzl0hAD2LkShsPql1IlZ.md index a11a930b7..a2d91ebc9 100644 --- a/src/data/roadmaps/software-design-architecture/content/minimize-cyclomatic-complexity@qZzl0hAD2LkShsPql1IlZ.md +++ b/src/data/roadmaps/software-design-architecture/content/minimize-cyclomatic-complexity@qZzl0hAD2LkShsPql1IlZ.md @@ -4,15 +4,15 @@ Cyclomatic complexity is a measure of the structural complexity of a program, wh Here are some ways to minimize cyclomatic complexity in system architecture: -- Break down complex functions into smaller, simpler functions that perform specific tasks. -- Use control structures, such as if-else statements and loops, in a consistent and predictable way. -- Use functional programming concepts and techniques, such as immutability and pure functions, to reduce the need for complex control flow. -- Use design patterns, such as the state pattern, to simplify complex control flow. -- Regularly review the code and refactor it to simplify the control flow. -- Use static code analysis tools that can detect and report high cyclomatic complexity in the code. +* Break down complex functions into smaller, simpler functions that perform specific tasks. +* Use control structures, such as if-else statements and loops, in a consistent and predictable way. +* Use functional programming concepts and techniques, such as immutability and pure functions, to reduce the need for complex control flow. +* Use design patterns, such as the state pattern, to simplify complex control flow. +* Regularly review the code and refactor it to simplify the control flow. +* Use static code analysis tools that can detect and report high cyclomatic complexity in the code. By following these best practices, the system architecture will be more maintainable, testable, and less error-prone. -Learn more from the following links: +Visit the following resources to learn more: -- [@article@How to reduce cyclomatic complexity?](https://kasp9023.medium.com/how-to-make-your-code-more-readable-focus-on-the-happy-path-and-reduce-cyclomatic-complexity-66802b8897b5) +- [@article@How to reduce cyclomatic complexity?](https://kasp9023.medium.com/how-to-make-your-code-more-readable-focus-on-the-happy-path-and-reduce-cyclomatic-complexity-66802b8897b5) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/model-driven-design@0VO_-1g-TS29y0Ji2yCjc.md b/src/data/roadmaps/software-design-architecture/content/model-driven-design@0VO_-1g-TS29y0Ji2yCjc.md index 26d60dd22..0368561e2 100644 --- a/src/data/roadmaps/software-design-architecture/content/model-driven-design@0VO_-1g-TS29y0Ji2yCjc.md +++ b/src/data/roadmaps/software-design-architecture/content/model-driven-design@0VO_-1g-TS29y0Ji2yCjc.md @@ -4,6 +4,6 @@ Model-driven design (MDD) is a software development methodology in which the des The main advantage of using MDD is that it allows for a clear separation of concerns between the design and implementation of a system. The models represent the design of the system, and the code is generated from the models, which makes it easier to maintain and evolve the system. Additionally, MDD can also improve the quality of the code, as the models can be used to check for design errors and inconsistencies before the code is generated. -Learn more from the following links: +Visit the following resources to learn more: -- [@article@Model Driven Design – theory to practice](https://www.todaysoftmag.com/article/1529/model-driven-design-theory-to-practice) +- [@article@Model Driven Design – theory to practice](https://www.todaysoftmag.com/article/1529/model-driven-design-theory-to-practice) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/model-view-controller@-arChRC9zG2DBmuSTHW0J.md b/src/data/roadmaps/software-design-architecture/content/model-view-controller@-arChRC9zG2DBmuSTHW0J.md index 941e276e5..472c8d167 100644 --- a/src/data/roadmaps/software-design-architecture/content/model-view-controller@-arChRC9zG2DBmuSTHW0J.md +++ b/src/data/roadmaps/software-design-architecture/content/model-view-controller@-arChRC9zG2DBmuSTHW0J.md @@ -2,7 +2,7 @@ Model-View-Controller (MVC) is an architectural pattern that separates the concerns of a software system into three distinct components: the model, the view, and the controller, where the model represents the data and the business logic of the system, the view represents the user interface of the system and the controller acts as an intermediary between the model and the view. The main goal of MVC is to separate the concerns of the system, making it easier to understand, maintain and evolve, it's widely used in web development. -Learn more from the following links: +Visit the following resources to learn more: - [@article@MVC Framework - Introduction](https://www.tutorialspoint.com/mvc_framework/mvc_framework_introduction.htm) -- [@video@Tutorial - MVC Architectural Pattern](https://www.youtube.com/watch?v=e9S90R-Y24Q) +- [@video@Tutorial - MVC Architectural Pattern](https://www.youtube.com/watch?v=e9S90R-Y24Q) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/monolithic@xYPR_X1KhBwdpqYzNJiuT.md b/src/data/roadmaps/software-design-architecture/content/monolithic@xYPR_X1KhBwdpqYzNJiuT.md index 5862ab002..b1facaad8 100644 --- a/src/data/roadmaps/software-design-architecture/content/monolithic@xYPR_X1KhBwdpqYzNJiuT.md +++ b/src/data/roadmaps/software-design-architecture/content/monolithic@xYPR_X1KhBwdpqYzNJiuT.md @@ -4,8 +4,8 @@ In software architecture, monolithic architecture is a design approach in which A monolithic architecture is often used for small to medium-sized systems, where the complexity of the system is manageable and the need for scalability and flexibility is not as high. In a monolithic architecture, the entire system is typically built, deployed, and executed as a single unit, which can make it easier to understand and manage the system. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Overview of Monolithic Architecture](https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith) - [@article@What is Monolithic architecture?](https://www.techtarget.com/whatis/definition/monolithic-architecture) -- [@video@What is Software Architecture? (Monolithic vs. Layered vs. Microservice)s](https://www.youtube.com/watch?v=_07NtoK-Kns) +- [@video@What is Software Architecture? (Monolithic vs. Layered vs. Microservice)s](https://www.youtube.com/watch?v=_07NtoK-Kns) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/object-oriented-programming@HhYdURE4X-a9GVwJhAyE0.md b/src/data/roadmaps/software-design-architecture/content/object-oriented-programming@HhYdURE4X-a9GVwJhAyE0.md index 3b225e639..d2af3f1b0 100644 --- a/src/data/roadmaps/software-design-architecture/content/object-oriented-programming@HhYdURE4X-a9GVwJhAyE0.md +++ b/src/data/roadmaps/software-design-architecture/content/object-oriented-programming@HhYdURE4X-a9GVwJhAyE0.md @@ -2,8 +2,8 @@ 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: +Visit the following resources to learn more: - [@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) +- [@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) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/object-oriented-programming@VZrERRRYhmqDx4slnZtdc.md b/src/data/roadmaps/software-design-architecture/content/object-oriented-programming@VZrERRRYhmqDx4slnZtdc.md index b3a27df01..ca807c114 100644 --- a/src/data/roadmaps/software-design-architecture/content/object-oriented-programming@VZrERRRYhmqDx4slnZtdc.md +++ b/src/data/roadmaps/software-design-architecture/content/object-oriented-programming@VZrERRRYhmqDx4slnZtdc.md @@ -2,8 +2,8 @@ Object-oriented programming (OOP) is a programming paradigm that uses objects and classes to structure and organize code. In OOP, an object is an instance of a class, which is a template that defines the properties and behaviors of the object. OOP is based on the principles of encapsulation, inheritance, and polymorphism. -Learn more from the following links: +Visit the following resources to learn more: - [@article@What is Object Oriented Programming?](https://www.freecodecamp.org/news/what-is-object-oriented-programming/) - [@article@OOP introduction](https://www.geeksforgeeks.org/introduction-of-object-oriented-programming/) -- [@feed@Explore top posts about OOP](https://app.daily.dev/tags/oop?ref=roadmapsh) +- [@feed@Explore top posts about OOP](https://app.daily.dev/tags/oop?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/object-oriented-programming@qZQDOe2MHBh8wNcmvkLQm.md b/src/data/roadmaps/software-design-architecture/content/object-oriented-programming@qZQDOe2MHBh8wNcmvkLQm.md index 3b225e639..d2af3f1b0 100644 --- a/src/data/roadmaps/software-design-architecture/content/object-oriented-programming@qZQDOe2MHBh8wNcmvkLQm.md +++ b/src/data/roadmaps/software-design-architecture/content/object-oriented-programming@qZQDOe2MHBh8wNcmvkLQm.md @@ -2,8 +2,8 @@ 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: +Visit the following resources to learn more: - [@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) +- [@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) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/organize-code-by-actor-it-belongs-to@kp86Vc3uue3IxTN9B9p59.md b/src/data/roadmaps/software-design-architecture/content/organize-code-by-actor-it-belongs-to@kp86Vc3uue3IxTN9B9p59.md index d4d56f39b..d6045813e 100644 --- a/src/data/roadmaps/software-design-architecture/content/organize-code-by-actor-it-belongs-to@kp86Vc3uue3IxTN9B9p59.md +++ b/src/data/roadmaps/software-design-architecture/content/organize-code-by-actor-it-belongs-to@kp86Vc3uue3IxTN9B9p59.md @@ -1,22 +1,22 @@ # Organize Code by Actor It Belongs To -Organizing code by the actor it belongs to means structuring your codebase around the primary users, roles, or systems that interact with it. Instead of grouping code purely by technical layers (controllers, services, repositories), you group it by *who* or *what* uses the functionality. This improves cohesion, discoverability, and long-term maintainability. +Organizing code by the actor it belongs to means structuring your codebase around the primary users, roles, or systems that interact with it. Instead of grouping code purely by technical layers (controllers, services, repositories), you group it by _who_ or _what_ uses the functionality. This improves cohesion, discoverability, and long-term maintainability. Some key ideas behind this approach include: -* Actor-focused structure: Group related functionality by user roles, domains, or external systems (e.g., `admin`, `customer`, `payment-gateway`). -* High cohesion: Keep logic that changes for the same reason in the same place. -* Reduced coupling: Minimize dependencies between unrelated actors or domains. -* Clear ownership: Each module clearly represents a responsibility or business capability. -* Easier navigation: Developers can quickly find relevant code based on the actor they are working on. -* Scalability: The codebase grows more naturally as new actors or features are added. -* Improved testing: Actor-based modules are easier to test in isolation. -* Alignment with business logic: The structure mirrors real-world use cases and workflows. -* Better collaboration: Teams can own specific actors or domains. -* Cleaner boundaries: Encourages well-defined APIs between parts of the system. +* Actor-focused structure: Group related functionality by user roles, domains, or external systems (e.g., `admin`, `customer`, `payment-gateway`). +* High cohesion: Keep logic that changes for the same reason in the same place. +* Reduced coupling: Minimize dependencies between unrelated actors or domains. +* Clear ownership: Each module clearly represents a responsibility or business capability. +* Easier navigation: Developers can quickly find relevant code based on the actor they are working on. +* Scalability: The codebase grows more naturally as new actors or features are added. +* Improved testing: Actor-based modules are easier to test in isolation. +* Alignment with business logic: The structure mirrors real-world use cases and workflows. +* Better collaboration: Teams can own specific actors or domains. +* Cleaner boundaries: Encourages well-defined APIs between parts of the system. -Learn more from the following links: +Visit the following resources to learn more: -* [@article@Package by Feature vs Package by Layer](https://www.baeldung.com/java-packaging-structures) -* [@article@Screaming Architecture](https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html) -* [@feed@Explore top posts about Software Architecture](https://app.daily.dev/tags/software-architecture?ref=roadmapsh) +- [@article@Package by Feature vs Package by Layer](https://www.baeldung.com/java-packaging-structures) +- [@article@Screaming Architecture](https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html) +- [@feed@Explore top posts about Software Architecture](https://app.daily.dev/tags/software-architecture?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/orms@SYYulHfDceIyDkDT5fcqj.md b/src/data/roadmaps/software-design-architecture/content/orms@SYYulHfDceIyDkDT5fcqj.md index 919a4a8a5..f25b5b82c 100644 --- a/src/data/roadmaps/software-design-architecture/content/orms@SYYulHfDceIyDkDT5fcqj.md +++ b/src/data/roadmaps/software-design-architecture/content/orms@SYYulHfDceIyDkDT5fcqj.md @@ -4,7 +4,7 @@ ORM stands for Object-Relational Mapping, it is a technique used in enterprise a ORMs are designed to abstract away the complexity of working with a relational database and allow developers to interact with the database using a higher-level, object-oriented API. They provide a set of libraries and tools that map the objects in the code to the tables and rows in the database, and vice versa. This allows developers to work with the data using a familiar object-oriented paradigm, rather than having to write complex SQL queries. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Why do you need an ORM?](https://enterprisecraftsmanship.com/posts/do-you-need-an-orm/) -- [@feed@Explore top posts about Backend Development](https://app.daily.dev/tags/backend?ref=roadmapsh) +- [@feed@Explore top posts about Backend Development](https://app.daily.dev/tags/backend?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/peer-to-peer@Cf9Z2wxBcbnNg_q9PA6xA.md b/src/data/roadmaps/software-design-architecture/content/peer-to-peer@Cf9Z2wxBcbnNg_q9PA6xA.md index f9a61689e..311a906b1 100644 --- a/src/data/roadmaps/software-design-architecture/content/peer-to-peer@Cf9Z2wxBcbnNg_q9PA6xA.md +++ b/src/data/roadmaps/software-design-architecture/content/peer-to-peer@Cf9Z2wxBcbnNg_q9PA6xA.md @@ -4,7 +4,7 @@ Peer-to-peer (P2P) architecture is a distributed computing architecture in which The main advantage of using P2P architecture is that it allows for a more decentralized and fault-tolerant system. As there is no central authority, there is no single point of failure, and the network can continue to function even if some nodes fail. Additionally, P2P architecture can also improve scalability as the number of nodes in the network increases. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Peer to Peer Architecture](https://student.cs.uwaterloo.ca/~cs446/1171/Arch_Design_Activity/Peer2Peer.pdf) -- [@feed@Explore top posts about Peer-to-Peer](https://app.daily.dev/tags/peer-to-peer?ref=roadmapsh) +- [@feed@Explore top posts about Peer-to-Peer](https://app.daily.dev/tags/peer-to-peer?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/policy-vs-detail@b_PvjjL2ZpEKETa5_bd0v.md b/src/data/roadmaps/software-design-architecture/content/policy-vs-detail@b_PvjjL2ZpEKETa5_bd0v.md index 5c6acfe42..2795ebaba 100644 --- a/src/data/roadmaps/software-design-architecture/content/policy-vs-detail@b_PvjjL2ZpEKETa5_bd0v.md +++ b/src/data/roadmaps/software-design-architecture/content/policy-vs-detail@b_PvjjL2ZpEKETa5_bd0v.md @@ -4,4 +4,4 @@ In software architecture, the distinction between **policy** and **detail** refe Policy refers to the high-level decisions that define the overall behavior and structure of the system. These decisions include things like the overall architecture, the system's interface, and the major components and their interactions. Policy decisions are often made by architects and designers, and they set the overall direction for the system. -Detail refers to the low-level implementation details that are required to implement the policy decisions. These include things like the specific algorithms, data structures, and code that make up the system's components. Details are often implemented by developers and are responsible for the actual functioning of the system. +Detail refers to the low-level implementation details that are required to implement the policy decisions. These include things like the specific algorithms, data structures, and code that make up the system's components. Details are often implemented by developers and are responsible for the actual functioning of the system. \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/polymorphism@4DVW4teisMz8-58XttMGt.md b/src/data/roadmaps/software-design-architecture/content/polymorphism@4DVW4teisMz8-58XttMGt.md index ececfcfa0..b6433b1bf 100644 --- a/src/data/roadmaps/software-design-architecture/content/polymorphism@4DVW4teisMz8-58XttMGt.md +++ b/src/data/roadmaps/software-design-architecture/content/polymorphism@4DVW4teisMz8-58XttMGt.md @@ -4,10 +4,10 @@ Polymorphism is a concept in object-oriented programming (OOP) that allows objec There are two types of polymorphism: -- Compile-time polymorphism (also called static polymorphism or early binding) occurs when the type of the object that is going to be acted upon is determined at compile-time. This is achieved through method overloading, which allows multiple methods to have the same name but different parameters within the same class. -- Run-time polymorphism (also called dynamic polymorphism or late binding) occurs when the type of the object is determined at run-time. This is achieved through method overriding, which allows a child class to provide a specific implementation of a method that is already defined in its parent class. +* Compile-time polymorphism (also called static polymorphism or early binding) occurs when the type of the object that is going to be acted upon is determined at compile-time. This is achieved through method overloading, which allows multiple methods to have the same name but different parameters within the same class. +* Run-time polymorphism (also called dynamic polymorphism or late binding) occurs when the type of the object is determined at run-time. This is achieved through method overriding, which allows a child class to provide a specific implementation of a method that is already defined in its parent class. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Overview of Polymorphism in programming](https://www.bmc.com/blogs/polymorphism-programming/) -- [@video@What is polymorphism in programming?](https://www.youtube.com/watch?v=tIWm3I_Zu7I) +- [@video@What is polymorphism in programming?](https://www.youtube.com/watch?v=tIWm3I_Zu7I) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/posa-patterns@6VoDGFOPHj5p_gvaZ8kTt.md b/src/data/roadmaps/software-design-architecture/content/posa-patterns@6VoDGFOPHj5p_gvaZ8kTt.md index ad8ef5bcd..655794d8a 100644 --- a/src/data/roadmaps/software-design-architecture/content/posa-patterns@6VoDGFOPHj5p_gvaZ8kTt.md +++ b/src/data/roadmaps/software-design-architecture/content/posa-patterns@6VoDGFOPHj5p_gvaZ8kTt.md @@ -4,12 +4,12 @@ POSA (Pattern-Oriented Software Architecture) is a set of design patterns for de POSA patterns are divided into four categories: -- Partitioning Patterns -- Placement Patterns -- Routing Patterns -- Federation Patterns +* Partitioning Patterns +* Placement Patterns +* Routing Patterns +* Federation Patterns -Learn more from the following links: +Visit the following resources to learn more: -- [@video@POSA Pattern Examples](https://www.youtube.com/watch?v=iYNa_KcWxCU) - [@article@Overview of Pattern-Oriented Software Architecture](https://en.wikipedia.org/wiki/Pattern-Oriented_Software_Architecture) +- [@video@POSA Pattern Examples](https://www.youtube.com/watch?v=iYNa_KcWxCU) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/program-against-abstractions@UZeY36dABmULhsHPhlzn_.md b/src/data/roadmaps/software-design-architecture/content/program-against-abstractions@UZeY36dABmULhsHPhlzn_.md index 3d04957db..24fea401d 100644 --- a/src/data/roadmaps/software-design-architecture/content/program-against-abstractions@UZeY36dABmULhsHPhlzn_.md +++ b/src/data/roadmaps/software-design-architecture/content/program-against-abstractions@UZeY36dABmULhsHPhlzn_.md @@ -4,6 +4,6 @@ Programming against abstractions is a programming principle that suggests that c Programming against abstractions allows for more flexibility in the code. When changes are needed, they can be made to the implementation of the abstractions without affecting the code that uses them. This makes it easier to understand, test, and maintain the code. -Learn more from the following resources: +Visit the following resources to learn more: -- [@article@Overview of Abstraction principle](https://en.wikipedia.org/wiki/Abstraction_principle_(computer_programming)) +- [@article@Overview of Abstraction principle](https://en.wikipedia.org/wiki/Abstraction_principle_(computer_programming)) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/programming-paradigms@RgYq3YOJhPGSf5in1Rcdp.md b/src/data/roadmaps/software-design-architecture/content/programming-paradigms@RgYq3YOJhPGSf5in1Rcdp.md index 5bdb623d4..dab0e5614 100644 --- a/src/data/roadmaps/software-design-architecture/content/programming-paradigms@RgYq3YOJhPGSf5in1Rcdp.md +++ b/src/data/roadmaps/software-design-architecture/content/programming-paradigms@RgYq3YOJhPGSf5in1Rcdp.md @@ -2,12 +2,12 @@ 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 +* Imperative programming +* Functional programming +* Object-oriented programming +* Logic programming +* Declarative programming -Learn more from the following links: +Visit the following resources to learn more: -- [@article@Overview of Programming paradigm](https://en.wikipedia.org/wiki/Programming_paradigm) +- [@article@Overview of Programming paradigm](https://en.wikipedia.org/wiki/Programming_paradigm) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/programming-paradigms@TDhTYdEyBuOnDKcQJzTAk.md b/src/data/roadmaps/software-design-architecture/content/programming-paradigms@TDhTYdEyBuOnDKcQJzTAk.md index 5bdb623d4..dab0e5614 100644 --- a/src/data/roadmaps/software-design-architecture/content/programming-paradigms@TDhTYdEyBuOnDKcQJzTAk.md +++ b/src/data/roadmaps/software-design-architecture/content/programming-paradigms@TDhTYdEyBuOnDKcQJzTAk.md @@ -2,12 +2,12 @@ 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 +* Imperative programming +* Functional programming +* Object-oriented programming +* Logic programming +* Declarative programming -Learn more from the following links: +Visit the following resources to learn more: -- [@article@Overview of Programming paradigm](https://en.wikipedia.org/wiki/Programming_paradigm) +- [@article@Overview of Programming paradigm](https://en.wikipedia.org/wiki/Programming_paradigm) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/publish-subscribe@SX4vOVJY9slOXGwX_q1au.md b/src/data/roadmaps/software-design-architecture/content/publish-subscribe@SX4vOVJY9slOXGwX_q1au.md index fb52f2186..6edca8f99 100644 --- a/src/data/roadmaps/software-design-architecture/content/publish-subscribe@SX4vOVJY9slOXGwX_q1au.md +++ b/src/data/roadmaps/software-design-architecture/content/publish-subscribe@SX4vOVJY9slOXGwX_q1au.md @@ -4,7 +4,7 @@ The publish-subscribe pattern is a messaging pattern in which a publisher sends The main advantage of using the publish-subscribe pattern is that it allows for a clear separation of concerns between the publisher and the subscribers, and it can improve the flexibility and scalability of the system. Additionally, it allows for loose coupling between components, meaning that the publisher and subscribers are not aware of each other's existence, and can be developed, deployed, and scaled independently. -Learn more from the following links: +Visit the following resources to learn more: -- [@video@Publish-Subscribe Architecture (Explained by Example)](https://www.youtube.com/watch?v=O1PgqUqZKTA) - [@article@Tutorial - Publish–subscribe pattern](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern) +- [@video@Publish-Subscribe Architecture (Explained by Example)](https://www.youtube.com/watch?v=O1PgqUqZKTA) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/pure-functions@5S5A5wCJUCNPLlHJ5fRjU.md b/src/data/roadmaps/software-design-architecture/content/pure-functions@5S5A5wCJUCNPLlHJ5fRjU.md index 6919a8106..055cbd69f 100644 --- a/src/data/roadmaps/software-design-architecture/content/pure-functions@5S5A5wCJUCNPLlHJ5fRjU.md +++ b/src/data/roadmaps/software-design-architecture/content/pure-functions@5S5A5wCJUCNPLlHJ5fRjU.md @@ -2,9 +2,9 @@ A pure function is a specific type of function that meets the following criteria: -- It takes some input, known as arguments, and returns a value or output. -- It does not cause any observable side effects, such as modifying the state of the system or interacting with external resources. -- Given the same input, it will always return the same output. -- It does not depend on any state or variables that are outside of its scope. +* It takes some input, known as arguments, and returns a value or output. +* It does not cause any observable side effects, such as modifying the state of the system or interacting with external resources. +* Given the same input, it will always return the same output. +* It does not depend on any state or variables that are outside of its scope. -Pure functions are considered to be more predictable and easier to test, as their behavior is determined solely by the input they receive and their internal logic. They also make it easier to reason about the behavior of a program, since the output of a pure function is not affected by any external factors. Pure functions are often used in functional programming, where they are considered a key principle. They are also useful in concurrent and parallel programming, as they are less prone to race conditions and other concurrency-related issues. +Pure functions are considered to be more predictable and easier to test, as their behavior is determined solely by the input they receive and their internal logic. They also make it easier to reason about the behavior of a program, since the output of a pure function is not affected by any external factors. Pure functions are often used in functional programming, where they are considered a key principle. They are also useful in concurrent and parallel programming, as they are less prone to race conditions and other concurrency-related issues. \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/repositories@8y0ot5sbplUIUyXe9gvc8.md b/src/data/roadmaps/software-design-architecture/content/repositories@8y0ot5sbplUIUyXe9gvc8.md index 072e78b37..c0b063e8a 100644 --- a/src/data/roadmaps/software-design-architecture/content/repositories@8y0ot5sbplUIUyXe9gvc8.md +++ b/src/data/roadmaps/software-design-architecture/content/repositories@8y0ot5sbplUIUyXe9gvc8.md @@ -4,7 +4,7 @@ Repositories are a pattern used in enterprise application development to provide A repository is a pattern that can be used to organize the data access code and encapsulate the logic of retrieving and storing objects. Repositories provide a way to separate the concerns of the data access from the rest of the application, allowing the application code to be written against an interface and not a specific data storage technology. -Learn more from the following links: +Visit the following resources to learn more: -- [@video@Tutorial - Repository Design Pattern](https://www.youtube.com/watch?v=mb6bwnEaZ3U) - [@article@Introduction to Repository Design Patterns](https://cubettech.com/resources/blog/introduction-to-repository-design-pattern/) +- [@video@Tutorial - Repository Design Pattern](https://www.youtube.com/watch?v=mb6bwnEaZ3U) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/scope--visibility@b-YIbw-r-nESVt_PUFQeq.md b/src/data/roadmaps/software-design-architecture/content/scope--visibility@b-YIbw-r-nESVt_PUFQeq.md index 28415d68d..c402543a4 100644 --- a/src/data/roadmaps/software-design-architecture/content/scope--visibility@b-YIbw-r-nESVt_PUFQeq.md +++ b/src/data/roadmaps/software-design-architecture/content/scope--visibility@b-YIbw-r-nESVt_PUFQeq.md @@ -2,8 +2,8 @@ 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. +* 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. +There are variations of scope visibility based on the programming language, but these are the most common. \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/serverless-architecture@5WSvAA3h3lmelL53UJSMy.md b/src/data/roadmaps/software-design-architecture/content/serverless-architecture@5WSvAA3h3lmelL53UJSMy.md index 46db65dca..e90f23947 100644 --- a/src/data/roadmaps/software-design-architecture/content/serverless-architecture@5WSvAA3h3lmelL53UJSMy.md +++ b/src/data/roadmaps/software-design-architecture/content/serverless-architecture@5WSvAA3h3lmelL53UJSMy.md @@ -4,7 +4,7 @@ Serverless architecture is a design pattern that allows developers to build and This architecture pattern mainly focuses on the business logic and event-driven execution, rather than on server management. It allows developers to write and deploy code in small, single-purpose functions that are triggered by specific events, such as changes in a database or the arrival of new data in a stream. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Serverless Architecture Patterns in AWS](https://waswani.medium.com/serverless-architecture-patterns-in-aws-edeab0e46a32) -- [@feed@Explore top posts about Architecture](https://app.daily.dev/tags/architecture?ref=roadmapsh) +- [@feed@Explore top posts about Architecture](https://app.daily.dev/tags/architecture?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/soa@FysFru2FJN4d4gj11gv--.md b/src/data/roadmaps/software-design-architecture/content/soa@FysFru2FJN4d4gj11gv--.md index d5e96ca1b..1f9314aef 100644 --- a/src/data/roadmaps/software-design-architecture/content/soa@FysFru2FJN4d4gj11gv--.md +++ b/src/data/roadmaps/software-design-architecture/content/soa@FysFru2FJN4d4gj11gv--.md @@ -2,9 +2,9 @@ SOA (Service-Oriented Architecture) is an architectural pattern that is used to design and organize software systems as a collection of services that can be accessed over a network, these services are autonomous, self-contained units of functionality that can be reused and combined to create new functionality. SOA services are designed to be loosely coupled, meaning that they do not depend on the implementation details of other services, they communicate with each other through well-defined interfaces, usually using a protocol such as HTTP or SOAP. SOA provides several advantages over other architectural patterns, such as reusability, modularity, interoperability, and scalability. It can be implemented using a variety of technologies, such as Web Services, REST, and microservices. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Overview of Service-Oriented Architecture](https://medium.com/design-microservices-architecture-with-patterns/service-oriented-architecture-1e4716fbca17) - [@video@Tutorial - Service-Oriented Architecture -SOA](https://www.youtube.com/watch?v=jNiEMmoTDoE) - [@video@What is Service-Oriented Architecture](https://www.youtube.com/watch?v=_dFJOSR-aFs) -- [@feed@Explore top posts about Architecture](https://app.daily.dev/tags/architecture?ref=roadmapsh) +- [@feed@Explore top posts about Architecture](https://app.daily.dev/tags/architecture?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/solid@3XckqZA--knUb8IYKOeVy.md b/src/data/roadmaps/software-design-architecture/content/solid@3XckqZA--knUb8IYKOeVy.md index f2df58b4b..848ea551e 100644 --- a/src/data/roadmaps/software-design-architecture/content/solid@3XckqZA--knUb8IYKOeVy.md +++ b/src/data/roadmaps/software-design-architecture/content/solid@3XckqZA--knUb8IYKOeVy.md @@ -2,14 +2,14 @@ SOLID is an acronym that stands for five principles of object-oriented software development, which were first introduced by Robert C. Martin in the early 2000s. These principles are: -- Single Responsibility Principle (SRP) -- Open/Closed Principle (OCP) -- Liskov Substitution Principle (LSP) -- Interface Segregation Principle (ISP) -- Dependency Inversion Principle (DIP) +* Single Responsibility Principle (SRP) +* Open/Closed Principle (OCP) +* Liskov Substitution Principle (LSP) +* Interface Segregation Principle (ISP) +* Dependency Inversion Principle (DIP) -Learn more from the following resources: +Visit the following resources to learn more: - [@article@Get Started with SOLID](https://www.bmc.com/blogs/solid-design-principles/) - [@article@SOLID Principles](https://khalilstemmler.com/articles/tags/solid/) -- [@video@Tutorial - What are SOLID principle?](https://www.youtube.com/watch?v=aUCo5cy32kE) +- [@video@Tutorial - What are SOLID principle?](https://www.youtube.com/watch?v=aUCo5cy32kE) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/structural@86Jw9kMBD7YP5nTV5jTz-.md b/src/data/roadmaps/software-design-architecture/content/structural@86Jw9kMBD7YP5nTV5jTz-.md index 5d54898d7..2c4ff7068 100644 --- a/src/data/roadmaps/software-design-architecture/content/structural@86Jw9kMBD7YP5nTV5jTz-.md +++ b/src/data/roadmaps/software-design-architecture/content/structural@86Jw9kMBD7YP5nTV5jTz-.md @@ -4,11 +4,11 @@ Structural architecture in software refers to the organization and design of the There are several different structural architecture patterns and styles that can be used to design software systems, including: -- Monolithic: where the system is built as a single, integrated, and self-contained unit. -- 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. -- 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. -- Client-Server: where a client sends requests to a server, and the server responds to those requests -- Peer-to-Peer: where each node in the network acts as both a client and a server -- 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. +* Monolithic: where the system is built as a single, integrated, and self-contained unit. +* 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. +* 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. +* Client-Server: where a client sends requests to a server, and the server responds to those requests +* Peer-to-Peer: where each node in the network acts as both a client and a server +* 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. \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/structured-programming@VhSEH_RoWFt1z2lial7xZ.md b/src/data/roadmaps/software-design-architecture/content/structured-programming@VhSEH_RoWFt1z2lial7xZ.md index 535546de1..485583cd6 100644 --- a/src/data/roadmaps/software-design-architecture/content/structured-programming@VhSEH_RoWFt1z2lial7xZ.md +++ b/src/data/roadmaps/software-design-architecture/content/structured-programming@VhSEH_RoWFt1z2lial7xZ.md @@ -2,7 +2,7 @@ Structured programming is a programming paradigm that emphasizes the use of well-structured control flow constructs such as loops, conditionals, and subroutines. It was developed in the 1960s and 1970s as a reaction to the "spaghetti code" produced by the widespread use of goto statements. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Structured Programming Wikipedia](https://en.wikipedia.org/wiki/Structured_programming) -- [@feed@Explore top posts about General Programming](https://app.daily.dev/tags/general-programming?ref=roadmapsh) +- [@feed@Explore top posts about General Programming](https://app.daily.dev/tags/general-programming?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/tell-dont-ask@0rGdh72HjqPZa2bCbY9Gz.md b/src/data/roadmaps/software-design-architecture/content/tell-dont-ask@0rGdh72HjqPZa2bCbY9Gz.md index ed7ac738d..2946650bf 100644 --- a/src/data/roadmaps/software-design-architecture/content/tell-dont-ask@0rGdh72HjqPZa2bCbY9Gz.md +++ b/src/data/roadmaps/software-design-architecture/content/tell-dont-ask@0rGdh72HjqPZa2bCbY9Gz.md @@ -2,27 +2,25 @@ The Tell, Don’t Ask principle emphasizes that objects should be told what to do rather than being queried for their state and having decisions made externally. This promotes encapsulation and reduces coupling by keeping logic within the objects that own the data. -## Key Concepts +Key Concepts +------------ -- Instead of pulling data out of objects to make decisions, push the behavior into the object itself. -- Objects should be responsible for their own logic and state management. +* Instead of pulling data out of objects to make decisions, push the behavior into the object itself. +* Objects should be responsible for their own logic and state management. Asking style (bad): -``` -if (user.profile.isComplete()) { - // allow checkout -} -``` + if (user.profile.isComplete()) { + // allow checkout + } + Telling style (good): -``` -if (user.canCheckout()) { - // allow checkout -} -``` + if (user.canCheckout()) { + // allow checkout + } -Learn more from the following resources: +Visit the following resources to learn more: -- [@article@Tell, Don't Ask](https://martinfowler.com/bliki/TellDontAsk.html) +- [@article@Tell, Don't Ask](https://martinfowler.com/bliki/TellDontAsk.html) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/tests-should-be-fast-and-independent@mzt7fvx6ab3tmG1R1NcLO.md b/src/data/roadmaps/software-design-architecture/content/tests-should-be-fast-and-independent@mzt7fvx6ab3tmG1R1NcLO.md index 1239b2071..3a6025b93 100644 --- a/src/data/roadmaps/software-design-architecture/content/tests-should-be-fast-and-independent@mzt7fvx6ab3tmG1R1NcLO.md +++ b/src/data/roadmaps/software-design-architecture/content/tests-should-be-fast-and-independent@mzt7fvx6ab3tmG1R1NcLO.md @@ -6,22 +6,22 @@ Well-designed tests focus on validating behavior in isolation and execute quickl Some of the key principles of fast and independent tests include: -* Speed: Tests should execute quickly so they can be run frequently during development. -* Independence: Each test should run in isolation and not depend on the outcome or state of other tests. -* Determinism: Tests should produce the same result every time they are run. -* Isolation: External dependencies (databases, APIs, file systems, time) should be mocked or stubbed. -* Single Responsibility: Each test should verify one behavior or scenario. -* Easy Setup and Teardown: Tests should have minimal and clear setup logic. -* Reliability: Tests should fail only when the code under test is broken, not due to environment issues. -* Automation Friendly: Tests should be easy to run in CI/CD pipelines without special configuration. -* Maintainability: Tests should be easy to read, understand, and update as the code evolves. -* Feedback-Oriented: Test failures should provide clear and actionable feedback. +* Speed: Tests should execute quickly so they can be run frequently during development. +* Independence: Each test should run in isolation and not depend on the outcome or state of other tests. +* Determinism: Tests should produce the same result every time they are run. +* Isolation: External dependencies (databases, APIs, file systems, time) should be mocked or stubbed. +* Single Responsibility: Each test should verify one behavior or scenario. +* Easy Setup and Teardown: Tests should have minimal and clear setup logic. +* Reliability: Tests should fail only when the code under test is broken, not due to environment issues. +* Automation Friendly: Tests should be easy to run in CI/CD pipelines without special configuration. +* Maintainability: Tests should be easy to read, understand, and update as the code evolves. +* Feedback-Oriented: Test failures should provide clear and actionable feedback. Fast and independent tests improve developer productivity, encourage refactoring, and act as living documentation for the system’s behavior. -Learn more from the following links: +Visit the following resources to learn more: -* [@article@Unit Testing Best Practices](https://martinfowler.com/articles/practical-test-pyramid.html) -* [@article@Test Pyramid Explained](https://martinfowler.com/bliki/TestPyramid.html) -* [@article@Writing Reliable Tests](https://testing.googleblog.com/2014/05/testing-on-toilet-how-much.html) -* [@feed@Explore top posts about Testing](https://app.daily.dev/tags/testing?ref=roadmapsh) +- [@article@Unit Testing Best Practices](https://martinfowler.com/articles/practical-test-pyramid.html) +- [@article@Test Pyramid Explained](https://martinfowler.com/bliki/TestPyramid.html) +- [@article@Writing Reliable Tests](https://testing.googleblog.com/2014/05/testing-on-toilet-how-much.html) +- [@feed@Explore top posts about Testing](https://app.daily.dev/tags/testing?ref=roadmapsh) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/transaction-script@tyReIY4iO8kmyc_LPafp1.md b/src/data/roadmaps/software-design-architecture/content/transaction-script@tyReIY4iO8kmyc_LPafp1.md index 59691912a..90a5c5284 100644 --- a/src/data/roadmaps/software-design-architecture/content/transaction-script@tyReIY4iO8kmyc_LPafp1.md +++ b/src/data/roadmaps/software-design-architecture/content/transaction-script@tyReIY4iO8kmyc_LPafp1.md @@ -2,7 +2,7 @@ Transaction Script is a pattern used in enterprise application development that organizes business logic into a single procedural script. It is often used for simple CRUD (create, read, update, delete) operations, where all of the logic for a specific transaction is contained in a single script or function. This pattern is simple to implement and easy to understand, but can become unwieldy as the complexity of the application increases. Alternative patterns such as Domain-Driven Design (DDD) and the Active Record pattern may be more appropriate for more complex applications. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Transaction Script Pattern](https://gunnarpeipman.com/transaction-script-pattern/) -- [@video@Tutorial - Transaction Script Design Pattern](https://www.youtube.com/watch?v=fnsU9cqcY3I) +- [@video@Tutorial - Transaction Script Design Pattern](https://www.youtube.com/watch?v=fnsU9cqcY3I) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/use-correct-constructs@S1m7ty7Qrzu1rr4Jl-WgM.md b/src/data/roadmaps/software-design-architecture/content/use-correct-constructs@S1m7ty7Qrzu1rr4Jl-WgM.md index eff2e7f9c..8031b1283 100644 --- a/src/data/roadmaps/software-design-architecture/content/use-correct-constructs@S1m7ty7Qrzu1rr4Jl-WgM.md +++ b/src/data/roadmaps/software-design-architecture/content/use-correct-constructs@S1m7ty7Qrzu1rr4Jl-WgM.md @@ -6,4 +6,4 @@ When using correct constructs, the code should be organized in a logical and int Additionally, correct constructs also means to use the right constructs for the right problem, for example, if you want to iterate over an array, use a for loop instead of recursion and also, you should avoid using global variables and instead use function arguments and return values to pass data between different parts of the code. -By using correct constructs, the code will be more readable, more maintainable, and less prone to bugs, making it easier for other developers to understand, debug and extend the code. +By using correct constructs, the code will be more readable, more maintainable, and less prone to bugs, making it easier for other developers to understand, debug and extend the code. \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/usecases@gQ7Xj8tsl6IlCcyJgSz46.md b/src/data/roadmaps/software-design-architecture/content/usecases@gQ7Xj8tsl6IlCcyJgSz46.md index 9e2434c00..9494e2d84 100644 --- a/src/data/roadmaps/software-design-architecture/content/usecases@gQ7Xj8tsl6IlCcyJgSz46.md +++ b/src/data/roadmaps/software-design-architecture/content/usecases@gQ7Xj8tsl6IlCcyJgSz46.md @@ -4,13 +4,13 @@ Use Cases are a pattern used in enterprise application development to represent 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 +* 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: +Visit the following resources to learn more: -- [@article@Use Case Patterns](https://caminao.blog/how-to-implement-symbolic-representations/patterns/functional-patterns/use-case-patterns/) +- [@article@Use Case Patterns](https://caminao.blog/how-to-implement-symbolic-representations/patterns/functional-patterns/use-case-patterns/) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/value-objects@Ks6njbfxOHiZ_TrJDnVtk.md b/src/data/roadmaps/software-design-architecture/content/value-objects@Ks6njbfxOHiZ_TrJDnVtk.md index 33fce434e..b375861f4 100644 --- a/src/data/roadmaps/software-design-architecture/content/value-objects@Ks6njbfxOHiZ_TrJDnVtk.md +++ b/src/data/roadmaps/software-design-architecture/content/value-objects@Ks6njbfxOHiZ_TrJDnVtk.md @@ -4,7 +4,7 @@ Value Objects are a pattern used in enterprise application development to repres A Value Object is defined by its value rather than its identity, meaning that two Value Objects with the same value are considered to be equal, regardless of their identity. -Learn more from the following links: +Visit the following resources to learn more: - [@article@Overview - Implement Value Objects](https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/implement-value-objects) -- [@article@Intro to Value object](https://en.wikipedia.org/wiki/Value_object) +- [@article@Intro to Value object](https://en.wikipedia.org/wiki/Value_object) \ No newline at end of file diff --git a/src/data/roadmaps/software-design-architecture/content/yagni@eEO-WeNIyjErBE53n8JsD.md b/src/data/roadmaps/software-design-architecture/content/yagni@eEO-WeNIyjErBE53n8JsD.md index 0f0a5abb8..a3ddc67b4 100644 --- a/src/data/roadmaps/software-design-architecture/content/yagni@eEO-WeNIyjErBE53n8JsD.md +++ b/src/data/roadmaps/software-design-architecture/content/yagni@eEO-WeNIyjErBE53n8JsD.md @@ -4,7 +4,7 @@ YAGNI (You Ain't Gonna Need It) is a software development principle that suggest The YAGNI principle is closely related to the Single Responsibility Principle (SRP) and the Open-Closed Principle (OCP), which are part of the SOLID principles. YAGNI aims to keep the codebase as simple as possible by avoiding the creation of unnecessary abstractions and functionality. -Learn more from the following resources: +Visit the following resources to learn more: - [@article@YAGNI (You Aren't Gonna Need It) Principle Helps in Efficiency](https://builtin.com/software-engineering-perspectives/yagni) -- [@video@What is YAGNI coding rule, and Why it helps?](https://www.youtube.com/watch?v=2vys1q1dKc4) +- [@video@What is YAGNI coding rule, and Why it helps?](https://www.youtube.com/watch?v=2vys1q1dKc4) \ No newline at end of file