Kourosh Ebrahiminejad’s Post

Good architecture whispers. Bad architecture shouts. That’s exactly how I see the Interface Segregation Principle in action. You don’t need one giant interface doing everything - you need small, focused contracts that quietly keep your domain clean. Here’s how I keep things clean:   public interface ISoftDeletable   {   bool IsDeleted { get; set; }   }       public interface IExpirable   {   DateTime? PublishDateTime { get; set; }   DateTime? ExpiryDateTime { get; set; }   bool IsPublished { get; }   bool IsExpired { get; }   }   public interface ITrackable   {   DateTime CreatedAt { get; set; }   DateTime? ModifiedAt { get; set; }   } And in my domain:   public class Page : Int32EntityBase, IExpirable, ITrackable   {   // Properties omitted for brevity       public DateTime? PublishDateTime { get; set; }   public DateTime? ExpiryDateTime { get; set; }   public bool IsPublished { get; private set; }   public bool IsExpired { get; private set; }       public DateTime CreatedAt { get; set; }   public long CreatedById { get; set; }   public DateTime? ModifiedAt { get; set; }   public long ModifiedById { get; set; }   } Each entity gets only what it really needs. No extra noise. No “NotImplementedException” drama. ✅ Why it works - Clean separation of concerns - Easier to test and refactor - More composable and reusable - Better readability and intent clarity Because at the end of the day: Good design doesn’t scream for attention - it just works.  #DotNet #CSharp #SOLID #InterfaceSegregation #CodeQuality #CleanCode

When you ask what interface segregation is? people usually say "single responsibility, but for interfaces". However, this is a good explanation by Kourosh Ebrahiminejad

The hard part is not defining a target architecture, it's finding a path that allows us to close the gap in appropriate and timely steps. Even when we can be sure at the start of a product that we will not pivot regarding the problem to solve, we still need to find a way to deliver value fast and experiment with the models we have in mind. Defining a target architecture that will be robust, resilient and adapt to many possible cases is nice, but if we try to implement directly an approach using distributed systems, redundancy of information, projections and async queues, before we even validate the the domain models and their interactions, we're in for a surprise. Not all the obstacles on the ground are visible from the ivory tower. One day maybe LLMs and assisted coding will be good enough so that implementing a diagram will be as easy as pointing to the destination in the map and boarding a plane to get there. But for now, we have to deal with the months-long travel, defining itineraries that allows us to restock, deal with the uncertainties of the terrain, and with the fact that the destination might change while we're in the way. That's the hard part.

What can we say about Architecture vs. Simplicity? We love clean architecture, but sometimes, the cleanest code is the one that’s simple enough to change. In one of my projects, I wanted the architecture to be as clean and scalable as possible, so I did what many of us do — added layers, interfaces, abstractions, and patterns everywhere. It looked beautiful on paper… but it slowed me down. Then I learned something important - "Good architecture isn’t about how many patterns you use — it’s about how easily you can change your code later" I started cutting unnecessary complexity: - I kept Vertical Slice + Minimal API because it made the structure clearer. - I dropped MediatR because it added more ceremony than value. - I simplified services to use EF Core directly, when it made sense. The result? - Faster iteration - Less boilerplate - Code that fits the needs of the project, not someone else’s diagram of “Clean Architecture.” Maybe simplicity is the most underrated part of good design. #dotnet #csharp #softwarearchitecture #cleanarchitecture #minimalapi #verticalslice #developerlife #backenddevelopment

Are you feeling the "spaghetti code" creep in your SwiftUI navigation? Ever struggled to deep-link users from a push notification, or pop back to the root after a purchase? My new article, "The SwiftUI Navigation Architecture That Will Save Your Projects: The Router Pattern" offers a comprehensive solution. Learn how to build a robust and maintainable navigation system with NavigationStack that will save your projects from chaos. #SwiftUI #iOSDevelopment #CleanCode #Navigation #Architecture #Programming

This article explains how to apply hexagonal architecture in Rust to build cleaner, more maintainable applications. It shows how separating domain logic from external concerns through traits and adapters can make code easier to test and evolve in theory. The author does a good job refactoring a messy example into a well-structured design without getting lost in abstractions. But in real projects, things are rarely that simple — swapping a database or major dependency is never just about changing an adapter. It usually involves deep redesign, refactoring, and embracing the unique capabilities of the new system, which no architecture can fully abstract away. Hexagonal architecture is a nice conceptual model, but in large, complex applications, it often remains more of an ideal than a practical day-to-day tool. https://lnkd.in/gnJzJWEN #rust #rustlang #architecture #softwaredesign #softwaredesignpattern

🧱 Why Clean Architecture Matters Clean architecture isn’t just a fancy concept or a set of nice-looking diagrams. It’s the foundation that determines how long your project can live without pain. 💡 Imagine this: your code is like a building. If the foundation is shaky, new floors (features) will eventually start to crumble. That’s why architecture isn’t about “how to code faster,” but rather “how not to rewrite everything six months later.” 🔍 Key benefits of clean architecture: 1. Modularity — each layer has its own responsibility. Less “magic,” more control. 2. Testability — isolated logic makes unit tests painless. 3. Flexibility — you can swap databases, UI, or even frameworks without touching the core domain. 4. Scalability — easy to add new modules or integrations without a domino effect. 5. Clarity — it’s clear where business logic ends and infrastructure begins. ❗❗ And here’s the part many overlook. Clean architecture isn’t just about technical purity — it’s also about business simplicity. Maintaining and evolving a well-structured system is simply cheaper for the business. 🧠 Most importantly — clean architecture helps you think like an engineer, not a firefighter. You don’t just react to bugs — you shape the system’s growth. 💬 How do you approach architecture in your projects? Have you ever had to “rescue” code because there was no clear structure?

Group related concepts together = build better applications 💡 Another name for this is cohesion, where we want to maximize the "relatedness" of files for a single feature. Layered architectures typically have low cohesion. The problem? They force you to make changes in many different layers to implement or update a feature. Vertical slices take a different approach. All the files for a single use case are grouped together, which increases their cohesion. It's easy to find all the relevant components for a feature. You can learn more about VSA here: https://lnkd.in/e-TKtnay What do you think about this approach? --- Sign up for the .NET Weekly with 74K+ other engineers, and get a free Clean Architecture template: https://lnkd.in/eDqzAKsP

Do you know Vertical slices architecture? Check the below post! Vertical slices architecture is a Screaming architecture! Screaming Architecture (a term from Uncle Bob’s Clean Architecture book) says that: “When you look at the top-level directory structure of a project, it should scream what the system does — not what framework it uses.”

One convenient way to organize your solution is below. It's often used when you're not ready to build a microservices architecture right now, but are considering it in the future. Using this architecture will make it easier to split your monolith into microservices.