PDF Summary:Clean Architecture, by Robert C. Martin

How do you build a software system that can easily adapt as requirements change without accruing technical debt or crippling the productivity of developers? In Clean Architecture, Robert C. Martin presents a set of principles and patterns to create applications with impeccable architecture that can withstand the test of time.

The key focus is separating the essential business rules from implementation details. This separation allows you to defer critical decisions about databases, frameworks, and other technological components, making the core system adaptable and maintainable. Martin also emphasizes the role of testing, treating tests as an integral part of system architecture to ensure correctness and flexibility.

(continued)...

A layer that conceals the specifics of the hardware in embedded systems ensures that the complex software is kept separate and independent from the hardware elements.

The principles of Clean Architecture are equally critical when implemented in embedded systems. Martin, drawing on insights from James Grenning, emphasizes the criticality of ensuring that the core software of embedded systems remains as autonomous as possible from the hardware it operates upon. The method prioritizes the creation of a layer that conceals the intricacies of the hardware, thus distinguishing between the software interacting with the hardware and the elements that operate independently of the hardware.

Martin underscores the importance of upholding this separation to ensure the software remains effective over time. Software maintains its usefulness over time when it is crafted to operate independently of specific hardware components that might become obsolete. The architecture of the system must be designed with precision to ensure that dependencies originate from the fundamental hardware level and progressively move toward the increasingly abstract layers of the software, in alignment with the Dependency Rule.

Practical Tips

• Try customizing your smartphone's interface with a launcher app to get a feel for how software layers can change user experience without altering the underlying system. Launchers on smartphones act as a middle layer between the user and the phone's software, allowing you to change icons, layouts, and gestures without affecting the core functions of the phone. This hands-on experience can give you a practical understanding of how software layers work.
• Consider learning about containerization technologies like Docker, which enable applications to run in isolated environments. Containers package software with all its dependencies, making the application run the same, regardless of the underlying hardware. Start with a simple tutorial to containerize a basic application, such as a web server, to understand how software can remain autonomous from hardware.
• Consider using cloud-based software solutions for your everyday tasks. Services like Google Docs or Adobe Creative Cloud maintain software effectiveness by being independent of your hardware. You can access your work from any device, ensuring that your productivity isn't tied to the performance of a single machine.
• Experiment with organizing your computer files according to the Dependency Rule. Arrange your folders so that system and application files are at the root level, and your documents and media are layered above them. This will give you a hands-on experience with structuring dependencies and might even improve your file management system's efficiency.

In distributed systems, services are structured into components that follow strong design principles, aiding in the avoidance of typical challenges inherent in service-oriented architecture.

Martin argues that the benefits often attributed to service-oriented architecture, such as strong compartmentalization and the independent development and deployment of components, are frequently misunderstood. He cautions that although services may operate independently in executing operations and handling variables, their interconnectedness remains due to the exchanged data. Martin underscores the deep interconnection between the processes of creating and rolling out software, as they often entail the addition of fresh functionalities and enhancements across multiple services, which requires careful coordination.

Martin advises building services that are in alignment with clean architecture tenets instead of relying on mere division of services. The author of "Clean Architecture," Robert C. Martin, asserts that by distributing responsibilities among different services and adhering to the Dependency Principle, it is possible to develop and deploy services independently, which minimizes complications that arise from intertwined concerns.

Context

• This refers to the ability to develop and deploy services without affecting others. Achieving this requires careful design to ensure that services have well-defined interfaces and that changes are backward compatible.
• SOA can lead to data management challenges, as services often need to share and synchronize data, which can complicate data consistency and integrity.
• Some services may require orchestration to manage workflows that span multiple services. This coordination can create dependencies, as the orchestrator needs to ensure that each service completes its task in the correct sequence.
• Coordinating the rollout of software involves assessing and mitigating risks associated with new deployments, such as potential downtime, security vulnerabilities, or performance issues.
• By structuring code according to Clean Architecture principles, it becomes easier to write unit tests for individual components, leading to more reliable and bug-free software.
• These are key design goals in clean architecture. Loose coupling ensures that services are minimally dependent on each other, while high cohesion ensures that the functionality within a service is closely related, making the system more robust and adaptable.
• This principle suggests that high-level modules should not depend on low-level modules, but both should depend on abstractions. This reduces the risk of changes in one part of the system causing unexpected issues in another.

In web-based applications, the framework is considered a supporting component, with the primary objective being to maintain a clear distinction between the core business processes and the elements of the user interface.

Martin emphasizes the critical role of the internet as a mere conduit for data transfer, similar to the function of an input/output component, without altering the core architecture of your system. The recommendation from Robert C. Martin is that web frameworks should be considered as elements that are part of the outer layers of a system's structure, rather than being the driving force behind the architecture's design.

Martin explains that by isolating the fundamental business operations from the user interface and the foundational web infrastructure, one can create a system that maintains its strength despite the ever-changing web technology environment. He underscores the necessity of isolating the core business processes of the application from the intricacies involved in user interface exchanges and visual presentations, to guarantee that the evolution of user interface technology remains without impact on them.

Other Perspectives

• The rise of full-stack development and frameworks that cater to this trend may blur the lines between backend and frontend, potentially leading to a more intertwined architecture where the framework influences both core business processes and user interface elements.
• The rise of web-based applications has led to architectures like microservices, where the internet is integral to the design and not just a data conduit.
• Web frameworks often come with their own set of architectural patterns and best practices, which can influence the overall design of an application, suggesting that they can be more than just outer layer elements.
• The strategy might not be suitable for all types of web applications, especially those that require real-time interaction and tight integration between the user interface and business logic, such as online gaming or collaborative tools.
• In agile development environments, the need for rapid iteration and close collaboration between UI designers and backend developers can be hampered by a strict separation, potentially slowing down the development process and reducing the team's ability to quickly adapt to user feedback.

The book explores the fundamental principles of developing and programming practices that are essential for structuring complex systems, encompassing their components and types.

Programming paradigms like structured and functional have distinct guidelines that shape different aspects of code development, similar to the foundational concepts inherent in the object-oriented approach.

Martin notes that each of the three primary programming methodologies requires a unique form of discipline from developers. He observes that these paradigms restrict certain capabilities, rather than providing new ones, and guide programmers away from harmful practices, rather than dictating specific approaches.

Structured programming emphasizes meticulous control over direct control flow, whereas object-oriented programming focuses on meticulous management of indirect control flow, and functional programming is characterized by its strict regulation of variable assignment.

Martin characterizes structured programming as a discipline that restricts the haphazard progression of control flow. The book emphasizes the significance of incorporating structured programming features like conditional and iterative constructs, which make the reliance on goto statements redundant. Martin contends that this method of programming necessitates an organized framework to oversee indirect control transfers, thereby not only establishing a robust and transparent foundation for polymorphism but also promoting flexible administration while postponing the determination of implementation details. Lastly, the method of coding that emphasizes immutable data and pure functions stringently confines the alteration of variables, thus addressing problems associated with mutable state in systems that function in parallel.

Other Perspectives

• The focus on control flow restriction might not address all types of programming errors or design flaws, such as logical errors or issues arising from the interaction between different modules or services.
• In some programming languages, particularly those that are not fully structured, goto statements are still a necessary tool for certain tasks where structured constructs are not available or are too cumbersome to use.
• Structured programming can be implemented without a complex framework for managing indirect control flow, as it relies on clear, straightforward constructs that are inherently organized.
• OOP can lead to situations where the control flow is obscured by layers of abstraction, which may not align with the idea of meticulous management.
• Object-oriented programming (OOP) can sometimes lead to less efficient polymorphism due to the overhead of dynamic dispatch.
• Postponing implementation details can also be a drawback as it may lead to a lack of clarity and increase the complexity of the system, making it harder to understand and maintain.
• In some cases, the strict use of immutable data can lead to less efficient algorithms, as some operations are more naturally expressed through mutable state.
• Functional programming's approach to managing state can lead to a steeper learning curve for developers unfamiliar with its principles, potentially affecting productivity and adoption.

The foundational tenets of SOLID advocate for the careful distribution of functions and data across separate classes and components, with the goal of isolating concerns and meticulously managing dependencies.

Robert C. Martin characterizes the SOLID principles as a set of recommendations that enhance a system's maintainability and flexibility by organizing functions and data structures in a way that improves the structuring of classes and components.

The tenets of Single Responsibility and Open-Closed suggest that code should be structured around shared reasons for modification and permit improvements without the need to modify existing code, while the Liskov Substitution Principle ensures that the application's operations are preserved when a derived type is substituted for its base type.

Responsible to a single stakeholder or actor, a module should have only one reason to change. This principle advocates for a modular design that minimizes the impact of changes. The Open-Closed Principle (OCP) encourages the design of modules that can be extended with new functionalities without the need to modify existing code. The Liskov substitutability principle asserts that the exchange of a superclass with one of its subclasses should not cause any interruptions in the program's operation. This principle bolsters the system's modularity by facilitating the effortless interchangeability of components, thus augmenting the adaptability of their implementations.

Context

• When a module has only one reason to change, it simplifies testing and debugging processes, as developers can isolate and address issues within a specific context without unintended side effects.
• SRP aligns well with agile methodologies, which emphasize iterative development and frequent changes, as it allows for more manageable and less risky updates.
• Many design patterns, such as Strategy, Decorator, and Observer, inherently support the Open-Closed Principle by allowing behavior to be extended without modifying existing code.
• A classic example involves a rectangle and a square. While a square is a type of rectangle, substituting a square for a rectangle in a program that expects to modify width and height independently can lead to incorrect behavior, illustrating a violation of LSP.
• LSP is closely related to the concept of design by contract, where a class and its subclasses adhere to a contract defined by the superclass. This contract includes preconditions, postconditions, and invariants that must be respected.

The guidelines that govern the consistency and interdependence of components encompass the principle that components should be reused and released together, the principle that classes that change for the same reasons should be grouped together, and the principle that classes that are reused together should be grouped together.

Martin underscores the importance of robust design tenets, which are relevant not only to the overarching framework but also to the individual components that become part of more expansive systems. The organization of classes and modules is designed to segregate them into separate entities, which enhances their reusability while simplifying their maintenance.

The principles in question provide guidance on structuring classes and modules in a manner that facilitates their deployment as components, while also promoting their reusability and simplifying their upkeep.

The Reuse/Release Equivalence Principle (REP) suggests that the level at which software components are reused should correspond with the level at which they are released, providing a harmonious and effective structure for both developers and users. The Common Closure Principle (CCP) advocates for the grouping of classes that are likely to undergo changes for the same reasons into a single component. The Common Reuse Principle (CRP) suggests grouping classes that are often used together into a single component. Martin notes that architects need to adeptly balance these principles in a way that is customized to meet the unique needs of their system.

Other Perspectives

• In some cases, it might be more practical to release small, incremental updates to components rather than aligning these releases with larger, less frequent reuse cycles, which can provide users with faster access to improvements and bug fixes.
• The CCP may lead to tightly coupled components, which can become problematic if changes in one class necessitate changes in all classes within the component, potentially increasing the risk of bugs and making the system more fragile.
• Adhering strictly to CRP can sometimes conflict with other design principles, such as the Single Responsibility Principle (SRP), which suggests that a class should only have one reason to change.
• These principles are derived from object-oriented design, and their relevance might be limited or require adaptation in other paradigms such as functional programming or microservices architectures.

A core aspect of clean architecture involves separating the essential business rules from technological specifics, while also integrating testing as a fundamental component.

The book emphasizes the importance of designing systems that facilitate testing, considering tests to be integral components of the system's framework.

Martin underscores the critical role of testing by asserting that tests are fundamental elements of a robust system and warrant equal consideration as the system's other core components. He argues that the genuine measure of a robust architectural structure lies in its ability to be tested, and neglecting this aspect can lead to systems that are difficult to sustain and modify.

The testing API facilitates the creation of comprehensive tests for business logic that are independent of the user interface, databases, or any other variable components.

To create a design that promotes straightforward testing, it is crucial to construct the system in such a way that its internal workings have no impact on the testing procedures. Martin recommends establishing a specialized API designed for testing that enables the circumvention of security measures, the replacement of costly resources with alternatives for testing, and the arrangement of particular conditions necessary for testing. He argues that this API allows for the examination of your application's essential operations without interference from external components like user interfaces, data storage systems, or network services, ensuring that your tests are quick, reliable, and resistant to changes.

Practical Tips

• Try writing pseudo-code for a hypothetical test case related to your business logic. Even if you're not a programmer, pseudo-code is a simplified way to express the logic of a test without needing to know the syntax of a programming language. For example, if your business logic includes calculating discounts for customers based on purchase history, write out the logical steps that a test should verify, such as "Check if customer has made more than five purchases" followed by "Apply 10% discount to total price."
• Develop a checklist of design elements that are independent of the testing process to ensure they remain unchanged. If you're working on a software interface, your checklist might include items like color scheme, button placement, and font choice. By having this checklist, you can review each element before testing to confirm that none of these aspects will inadvertently affect the test outcomes.
• You can partner with a local university's computer science department to create a testing API as a class project. By doing so, you provide students with real-world experience while also developing a tool tailored to your needs. The students gain practical skills and you get a specialized API without the need for advanced technical knowledge.
• Engage in online simulations or games that focus on cybersecurity and ethical hacking to apply theoretical knowledge in a practical, risk-free environment. Look for platforms that offer interactive challenges and scenarios where you can practice identifying security vulnerabilities within an API. These simulations often provide instant feedback and can help you understand the complexities of API security in a hands-on way. By participating in these simulations, you can develop a more nuanced perspective on how security measures can be bypassed and the importance of robust security practices.
• Implement a swap service with peers to exchange skills and resources for mutual testing of projects. This barter system can help you access different resources without direct financial costs. For example, if you need graphic design skills to create a prototype but lack the funds to hire a professional, offer your own skills in writing, coding, or another area in exchange for design assistance.
• Experiment with different user scenarios by role-playing as a user with specific needs or limitations. For example, if you're testing a website, try navigating it using only keyboard shortcuts to simulate the experience of a user with limited mobility. This hands-on approach can help you uncover usability issues that might not be apparent through automated testing alone.
• Try integrating a simple, publicly available API into a basic webpage to see the concept in action. For example, use the OpenWeather API to fetch weather data and display it on a webpage you create. This will give you practical experience with how APIs can provide specific functionality to a system without needing to understand the complexities of the weather data sourcing.
• Develop a habit of running 'stress tests' on your daily routines to identify weak points. For instance, if you have a morning routine, try adjusting the order of tasks or timing to see if it holds up under different circumstances. This could mean exercising before and after breakfast on different days to see which is more sustainable and effective for you.

A core tenet of clean architecture involves clearly separating the overarching business rules from the specific implementation details.

Martin underscores the necessity of distinctly delineating the core business rules from the intricacies associated with technology to realize a pristine architectural framework. The system's overarching guidelines maintain their consistency and adaptability, even when specific details of the implementation change.

The system's core components and principles should be shielded from frameworks, databases, and other critical mechanisms, which are considered secondary and should be kept distinctly separate.

Martin positions elements such as web servers, databases, and frameworks as ancillary aspects that must be segregated from the system's essential business operations. He argues that details of this nature should be situated on the periphery, interacting with the core business logic as needed.

Practical Tips

• Create a 'principles jar' where you write down instances when you successfully made decisions based on your core principles rather than external pressures or immediate conveniences. This tangible collection serves as a reminder and reinforcement of the importance of sticking to your core components in daily life.
• Develop a simple storytelling narrative where characters represent the core system, web servers, databases, and frameworks. For example, imagine the core system as a 'hero' on a quest, while the web servers, databases, and frameworks are 'allies' that provide support without interfering with the hero's journey. This can help you internalize the idea of separation by associating it with familiar storytelling tropes.
• Create a "peripheral task day" in your weekly schedule dedicated to handling the non-core aspects of your projects. Choose a day of the week to focus solely on peripheral tasks such as updating software, backing up data, or reviewing analytics. By batching these tasks, you ensure they're addressed regularly without detracting from your daily focus on core activities.

The structuring of layers guarantees that modules with higher abstraction remain stable and adaptable in the face of alterations, while those at a lower level, which are more concrete, can be easily modified or replaced.

Martin emphasizes the significance of treating specific aspects of implementation as separate components that comply with the Dependency Rule, thereby facilitating the creation of a system that possesses both adaptability and flexibility. By segregating these elements, changes can be made to the core details after deployment or during later stages of development, while still maintaining the core principles of the system intact. As time progresses, the ease with which a system can be updated, modified, and enhanced typically increases.

Context

• Layers typically communicate through well-defined interfaces, which helps ensure that changes in one layer do not ripple through the entire system.
• By isolating specific functionalities, these components can be reused across different projects or parts of the same project, enhancing efficiency and consistency.
• Regular refactoring of segregated components can improve system design and accommodate changes without disrupting the overall architecture.
• Using version control allows developers to track changes to the codebase, ensuring that core principles are preserved even as core details are modified.
• Developers gain a deeper understanding of the system's architecture and behavior over time, which can lead to more effective and targeted updates and enhancements.