7Factor Software’s Post

𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗮𝗹 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗱𝗲𝘀𝗶𝗴𝗻: You are creating a class/code unit/ component but it depends on another code unit  which requires some configuration to instantiate. Is the component you are creating responsible for knowing how to create its dependencies? How do you deal with that? Here is the problem: You are wondering how your component is going to get the right configuration values to pass to its dependency so it can make an instance of that dependency. In a way, the component you are creating is coupled to the way its dependency is getting its ‘construction’ values. It is not really the responsibility of your component to know where that information is coming from. Your component is just interested in using that dependency. This is a perfect case to apply 𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗶𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻.  You inject this dependency in the constructor or using a setter, that doesn’t matter too much in most cases. What you are actually doing is pushing the responsibility of creating this dependency to a dedicated component  responsible for creating objects and knowing where to get configuration values etc. You can build this ‘creator’ or ‘assembler’ yourself and take care of the injection or you can use a dependency injection framework to do this for you. Your component is now no longer coupled to the construction of its dependencies. Interested in learning more about practical and efficient software design? Don’t be shy, send me a DM and we can have a chat. #softwaredevelopment #softwareengineering #softwaredesign

💡 "Design is not just how something looks, it’s how it works. And for software, that starts with how we build it at a fundamental level." 💡 Software design can be a complex world, but it's one that every developer needs to master. That’s why I’m starting a daily series to break down Low-Level Design (LLD)—step by step, topic by topic. 🎯 📌 What is LLD? Low-Level Design is about the finer details of how individual components of a system interact. It’s where code structure, patterns, and best practices come together to create systems that are: 1. Efficient 🚀 2. Scalable 📈 3. Easy to maintain 🛠️ Why is this important? Because getting LLD right means building software that not only works today but adapts and grows with future needs. From design patterns to modularity, and everything in between, LLD is the backbone of resilient, long-lasting systems. Over the next few weeks, I’ll be sharing one key concept of LLD per day. Whether you’re new to design or have years of experience, I hope these posts will give you a fresh perspective on how to improve your design approach. 🔥 Ready to dive in? Here’s what’s coming up: 1️⃣ Understanding Design Patterns 2️⃣ Best Practices for Modular Design 3️⃣ The Role of SOLID Principles in LLD 4️⃣ How to Optimize Interactions Between Components What’s your biggest challenge when it comes to Low-Level Design? Drop a comment and let’s kick off the conversation! 👇 #LowLevelDesign #LLD #SoftwareEngineering #TechLeadership #SystemDesign #DesignPatterns #ScalableSystems #CareerGrowth #LearningJourney

Here are a few insights in how I effectively deal with tougher design decisions. Because software design is not just about different principles and techniques. At some point, you will encounter situations where you will need to make trade offs and then those principles and techniques won’t be much of help. - Enabling change is the most valuable thing in your code base. If you are in a really tough design situation, go for the solution that will enable change the most. Enabling change means that changes in your code should not force changes to code that have nothing to do with the original changes. It isn't really about how many code units are going to change, it is more about code that is forced to change along when it actually shouldn’t change along. The only thing that overrules enabling change is a very specific need of a group of stakeholders that is absolutely necessary for their business. - This means that you need to know the reasons for change. The main reasons for change are not in your codebase. The greatest motor of change is your group of stakeholders. So this is where you need to start asking about the why. Why are you writing certain code? Who are these stakeholders and what do they want? Get as much context as you can before making the decision. This can have a surprising impact on your design dilemma. - Don’t overvalue reusability. Reusability is not a top priority when you need to make trade offs. If you need to choose between reusability and enabling change, you should prioritise enabling change. - The same thing applies to DRY and code duplication. This is actually very related to reusability. If you need to choose between duplication which enables change and DRY your code, pick the duplication to enable change. - Consider the value of your time thinking about the decision ahead: how much impact on the code will this decision have? If the impact is really small and if it doesn’t impact the ability of your code to change, pick the simplest solution possible. #softwaredevelopment #softwareengineering #softwaredesign

🌟 Daily Development & Design Insights 🌟 🔍 Topic of the Day: The Power of Cohesive Software Design Cohesive software design is about creating modules and classes where all elements work together toward a common goal. Here’s why it matters: 1️⃣ Single Responsibility Principle (SRP) Focus: Each module or class should do one thing and do it well, making your code easier to understand and change. 2️⃣ High Intra-Module Relatedness Purposeful Design: Keep methods and properties tightly related, ensuring everything within a class contributes to its primary function. 3️⃣ Low Coupling Modularity: While elements within a module are tightly connected, the module itself should be loosely connected to others, making your system more flexible. 4️⃣ Clarity and Maintainability Simplicity: Cohesive design leads to clearer, more maintainable code, where changes can be made without impacting unrelated parts. 5️⃣ Improved Reusability Efficiency: Modules that focus on a single task are easier to reuse in different contexts. 💡 Pro Tip: Aim for high cohesion in your software design to build systems that are easier to maintain, extend, and scale. Balance cohesion with low coupling to create a robust and flexible architecture. #SoftwareDesign #Cohesion #CleanCode #SoftwareArchitecture #SRP #Modularity #Maintainability #Scalability

𝗜𝘀 𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗗𝗲𝘀𝗶𝗴𝗻 𝗿𝗲𝗮𝗹𝗹𝘆 𝗗𝗲𝗮𝗱? Over an interesting post by Michele Sollecito where he maintains that software development is all design, there's been a lively conversation in the comment. I said in one of the comments that "𝗗𝗲𝘀𝗶𝗴𝗻 𝗶𝘀 𝗗𝗲𝗮𝗱" and the provocation was picked up. Here a brief comment on why I believe so. For the long answer, I am afraid you have to wait for my paper to be in a readable draft state (and please don't crowd 😀). For the short answer: https://lnkd.in/eEzRxqiK #softwaredesign

📌#SeparationOfConcerns is by far the most important aspect of software design.   It is the most powerful technique we have to control complexity.   👉The value lies in the ability to later improve or modify one section of code without needing to know the details of other sections – and without having to make changes to those sections.   All well-known design patterns and design practices aim to help us achieve a good separation of concerns. #CleanArchitecture is no exception.   💡A structure in code that enforces and preserves separation of concerns is crucial for complex and large systems. Without it, complexity gets out of hand, becomes uncontrolled, and projects fail.   I use  𝗮𝘀𝘀𝗲𝗺𝗯𝗹𝘆 𝗿𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲𝘀 and 𝗽𝗿𝗶𝘃𝗮𝘁𝗲 𝗶𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻𝘀 to build such a structure. A key principle in Clean Architecture is not to depend on frameworks, but rather make frameworks depend on your app. This is achieved through Dependency Inversion, where abstractions define the application's needs.   Therefore, in my designs, the rules for making assembly references are strict:  🔸No assembly can reference the assemblies that implement the application use cases (implementations are internal). No exceptions.  🔸Contract Assemblies (which contain only interfaces and DTOs, with no logic) are used to define application needs and service capabilities.   🛠Implementing this with #DependencyInjection (DI) is not trivial. The challenge is that the assembly containing the interface-implementation pairing code would need to reference the implementation assembly – breaking the rule. ⛔️   To solve this, you need to extend DI with a mechanism that, based on conventions or annotations, discovers all interface-implementation pairs at runtime when the application starts and configures DI accordingly. In most of my designs, this is done by the AppBoot component, which is the first piece in the application infrastructure I build. ⚙️   How do you enforce Separation of Concerns? 🤔     *** 🔔 if you enjoy my content, follow me Florin Coroș for more in the future ♻️ repost to share with your network ❤️ if you agree with this #softwaredesign #softwarearchitecture

Design is the stuff you have to think about upfront because you have to have at least some mental structure of the software you’re going to write. You don’t just sit down and start writing code. So whether design is an intentional act, accounted for in delivery processes and timelines, or whether it is considered an overhead cost or point of friction in the development process, it still has to happen. The problem with design-on-the fly is that it’s applied at the narrowest possible point - the point closest to the problem. This comes at the expense of the system as a whole because it introduces the risk of duplication, errors, incompatibility, coupling / dependencies, inefficiencies, and unnecessary complexity.

There are a handful of points that are crucial for rocking it in software design, but hardly anybody talks about them. And even though these points are simple, it feels like lost wisdom. This is what talking about: If you want to be really good at software design … … you need to understand what software design is and what you want to accomplish with it. In other words: we need to understand what the goal is and also what it concretely means … you need context. You need to acknowledge this context, recognize it and of course understand it. It is only by understanding the context which you are working that you will be able to make decent trade offs … you need to understand change in software and where it  is coming from. … you need to understand complexity, what it means in the context of software design and then be able to take complexity into account … you need to understand the evolution of the context you work in. Everything changes, not only the code you are working in. The funny thing is that when you talk to people about it, they will say: “Yeah, I already know that”. It feels like you have said the most obvious thing in the world. But very few of them are actually making use of it. It is great if you can talk the talk, but it is better if you can also walk the walk. #softwaredevelopment #softwareengineering #softwaredesign

System designers often fall into the trap of equating complexity with the volume of code. They assume that a shorter implementation is inherently simpler, and that changes requiring fewer lines of code are easier to make. However, this perspective overlooks a crucial factor: cognitive load. While some frameworks allow applications to be written in just a few lines of code, determining those exact lines can be extremely challenging. In many cases, an approach that requires more lines of code may actually be simpler because it reduces cognitive complexity. True simplicity in software design isn't just about minimizing code length. It's about creating systems that are easy to understand, maintain, and modify. Sometimes, a more verbose implementation can provide better clarity, making the code more accessible to developers and easier to work with in the long run. Ultimately, the goal should be to balance conciseness with readability and maintainability. The most effective code isn't necessarily the shortest, but rather the one that most clearly expresses its intent and functionality.

Building anything must have a design. That design must come from people who have understood what is required. Those requirements must come from people who need a solution. I think this is the approach we normally take to build software. The funny thing for me is each stage is a different conversation with a different group of people who speak different dialects and have different world views. Communication as a process misses many important elements but even if we just take the Shannon and Weaver approach, it's clear we are going to struggle. Shannon and Weaver proposed their mathematical theory of communication in 1948. Their model, which became known as the Shannon-Weaver model, was originally developed to improve technical communication, but it became widely applied to human communication as well. The basic elements of their model include: 1. An information source 2. A transmitter 3. A channel 4. A receiver 5. A destination 6. Noise (which can interfere with the signal) Now each of the steps we use to start with a problem and end with a solution has handovers where documents attempt to transmit information to the next stage. Someone with one skillset, mindset, worldview etc creates a document (encodes information) and someone with completely different worldview etc decodes the information before reencoding it to pass it onto the next stage. A codified version of the whisper game. Now add into that "prioritisation" of requirements based on predetermined budgets which have no correlation with the problem, political interference, practicalities, policies, process, levels of engagement, caring etc, the noise in the communication process. How do we expect to be able to deliver anything close to what we need? The really funny bit is we focus on the builders being "productive" without really thinking about all those handovers of increasingly contaminated requirements. Until we put the people with the problem in a room with the people who build solutions and get rid of all the noise and handovers, we will see failure. And don't get me started on timescales between problem identification and solution delivery.