Here’s how I interpreted SOLID principles from Clean Architecture by Robert C. Martin (Uncle Bob) Single Responsibility Principle: - A module or class should be responsible for one and only one actor (a group of people who want the system to be changed in the same way). - Elements that tend to change for the same reasons should be grouped in the same package or module. - Set architectural boundaries by identifying the axis of change (potential areas or dimensions of a system where changes are most likely to occur over time, e.g., business rules, UI, external systems). Open/Closed Principle: The goal is to make systems easy to extend and minimize the impact of change. This can be achieved by separating things that change for different reasons (SRP) and using dependency inversion to isolate the change. Liskov Substitution Principle: LSP can and should be applied at the architecture level. A system should have reliable interfaces that are substitutable. A single violation of LSP can pollute the architecture of the system with complex mechanisms. Interface Segregation Principle: There shouldn't be a dependency on a module containing more than you need. This leads to unnecessary recompilations, redeployments, and failures you don't need. Dependency Inversion: Avoid dependency on concrete implementations of volatile and actively developing modules. Rather, rely on less volatile interfaces. #SOLID #SoftwareArchitecture #CleanArchitecture
Aditya Sapate’s Post
More Relevant Posts
-
Do you document your architecture decisions in an IT project? Use a #retro meeting to document such occurrences, ask the team did it happen. Mention the topic if nothing else. Documentation? Remember to ask and it doesn't matter what role you play in AGILE train.
An architecture decision record aka #ADR is a short text file in a format similar to an Alexandrian pattern. Each record describes a set of forces and a single decision in response to those forces. Note that the decision is the central piece here, so specific forces may appear in multiple ADRs. * We will keep ADRs in the project repository under doc/arch/adr-NNN.md * We should use a lightweight text formatting language like Markdown or Textile. * ADRs will be numbered sequentially and monotonically. Numbers will not be reused. If a decision is reversed, we will keep the old one around, but mark it as superseded. (It's still relevant to know that it was the decision, but is no longer the decision.) We will use a format with just a few parts, so each document is easy to digest. https://lnkd.in/ecGeD_Rq https://lnkd.in/evsKfJAT
-
How much of Architecture Coverage is enough? At some point you probably asked yourselves.... Is our Architecture well documented? Will I be able to find the Diagram I'm looking for? Is this Diagram suitable for our discussion? Do we need more Diagrams? If yes, you're probably questioning your "Architecture Coverage". With C4 InterFlow you should be able to achieve (and maintain over time) close to a maximum level of Architecture Coverage. Check out some samples of Architecture as Code and auto-generated Diagrams here: https://lnkd.in/e3xr-4KF #ArchitectureAsCode #C4Model #ArchitectureDiagrams #DiagramAsCode
-
Practical .NET and Software Architecture Tips | Microsoft MVP
How would you add validation to a vertical slice? I prefer using FluentValidation for simple input validation. I can define the validator as a class in the vertical slice and use it from the use case. The Validator class encapsulates the rules specific to your feature's request model. It also supports dependency injection so that we can run complex validations here. This validator can then be injected into your endpoint (or use case), allowing you to validate before processing the request. Are you looking to get started with Vertical Slice Architecture? Here's a step-by-step guide: https://lnkd.in/eAEnMG7e Using this approach, I can keep my vertical slices fully encapsulated. --- Do you want to simplify your development process? Grab my free Clean Architecture template here: https://bit.ly/3UAgssW
-
-
To design software, I usually recommend software design principles over predefined recipes. I love Hexagonal Architecture, so I wanted to understand the why's under this approach. What are the problems Ports&Adapters try to solve and based on what design principles is built? https://lnkd.in/dw2h9NSj
The whys of hexagonal architecture
blog.devgenius.io
-
#cleanarchitecture ...has one goal: separation of concerns in a system into layers, independent of the frameworks utilized or the technologies that engrave the system. To do this, code is grouped based on what and how. Code that defines what an application does and when it should do it is called Policy. Code that implements how the policy is done is called detail. When you think about abstractions, interfaces, or business logic, you think policy. When you think about concretion, implementation, or infrastructure, you think of detail. As you may have noticed, details enforce what policies do. Think of policy as the law and detail as the police. Also, the D rule of the SOLID principles governs the relationship between policy and detail. D, in this context, stands for Dependency Inversion Principle which states that: "Abstractions should not depend on details, but details should depend on abstractions." I am not a SOLID expert, but I am solid on the D rule. Think of it this way: Details power Policies. If you drew a diagram, you could have two circles, one enveloping the other. The outer circle is where the detail lives while the inner circle is where the policy lives. Dependency here is an inward phenomenon. The outer layer depends on the inner layer, but not the same as vice versa. ——— While Clean Architecture is a vast topic (of course, I am no expert), I hope I was able to inform you on its fundamentals. Hence, next time you feel like using a concrete class as a type of a property in an interface, think again. Ask yourself: "Which is the policy? Which is the detail?" and apply the D rule. Bye!
-
-
Clean Architecture promotes the idea of modular, testable, and maintainable code. It emphasizes separating concerns and defining clear boundaries between system components. Clean Architecture is suitable for complex or long-lived applications, projects with a central domain model, and teams that prioritize clean code practices.
-
-
Hello everyone, I have decided to gain a deep understanding of software memory, design patterns, and common architectures. Please suggest a comprehensive book on these topics. Thanks for your comments and likes. 🙏🙏 #architecture #designpatterns #memory #softwaredevelopment
-
-
My research on software architectures continues with Onion and Clean architecture. I want to present the article in which I convey what I have learned. Have a good reading 📓 Clean Architecture: https://lnkd.in/dicwYFCG Onion Architecture: https://lnkd.in/dR3md4Wn
Intro to Onion Architecture
medium.com
-
Head of Engineering at smit.fit | Solution Architect | Cloud, Big Data, Data Science & AI | Backend, APP & Web Developer | Healthcare Startups
Tired of messy code? Learn how to build cleaner, more maintainable software with architectural design patterns. Watch full video here https://lnkd.in/ge9z7RMt #architecture #designpatterns #softwaredevelopment
