DEV Community: Jose Rodriguez Marrero

I Thought My Domain Entity Was Fine. A DDD Audit Said Otherwise.

Jose Rodriguez Marrero — Thu, 30 Apr 2026 23:53:35 +0000

I'm building Banderas, an open-source feature flag management system for .NET teams on Azure. A few weeks in, I had a working API — CRUD endpoints, evaluation logic, integration tests, the works. Phase 1 was done.

My entity bugged me. It just didn't look right. As I continue to study DDD, my eyes have started seeing things.

Then I ran a DDD audit on my core domain entity, Flag.cs. This was my first time running an audit like this using an agent. And this is also the first time that I'm being intentional in my DDD approach to this project.

What I found was uncomfortable and illuminating: my entity wasn't really a domain entity. It was a database row wearing a domain costume. This post is about what I found, why it mattered, and how I'm fixing it.

What I Started With (yes, I know. Be gentle)

Here's the original Flag.cs, simplified slightly:

public class Flag
{
    public Guid Id { get; private set; }
    public string Name { get; private set; }
    public EnvironmentType Environment { get; private set; }
    public bool IsEnabled { get; private set; }
    public bool IsArchived { get; private set; }
    public bool IsSeeded { get; private set; }
    public RolloutStrategy StrategyType { get; private set; }
    public string StrategyConfig { get; private set; }
    public DateTime CreatedAt { get; private set; }
    public DateTime UpdatedAt { get; private set; }
    public DateTime? ArchivedAt { get; private set; }

    public void SetEnabled(bool enabled) { ... }
    public void UpdateStrategy(RolloutStrategy strategyType, string? strategyConfig) { ... }
    public void Update(bool isEnabled, RolloutStrategy strategyType, string? strategyConfig) { ... }
    public void Archive() { ... }
}

On the surface, it looks fine. Private setters, behavior on the entity, timestamps — all the right signals. But when I started asking DDD questions, problems surfaced quickly.

Problem 1: `StrategyConfig` Is a Trust Exercise

The StrategyConfig property is a raw JSON string. Its default value is "{}".

That means this is completely legal:

flag.UpdateStrategy(RolloutStrategy.Percentage, "{}");

A percentage rollout with no threshold defined. The entity accepts it without complaint. Nothing breaks until runtime, when some code downstream tries to deserialize the threshold and gets nothing.

In DDD terms, this violates a core principle: make illegal states unrepresentable. The entity's job is to protect its own consistency. Right now, Flag is not doing that job for its most complex property.

The fix is to replace the raw string with typed Value Objects — one per strategy:

// Instead of: string StrategyConfig = "{}"
public sealed class PercentageConfig
{
    public int Threshold { get; }

    public PercentageConfig(int threshold)
    {
        if (threshold < 0 || threshold > 100)
            throw new ArgumentOutOfRangeException(nameof(threshold), 
                "Threshold must be between 0 and 100.");

        Threshold = threshold;
    }
}

Now invalid state can't be constructed. The type system enforces the rule — not a validator somewhere downstream.

Problem 2: `IsSeeded` Has No Business Being Here

public bool IsSeeded { get; private set; }

This flag (pun intended) tells the system whether a record was inserted by the database seeder. It's an infrastructure concern — and it's sitting in the middle of a domain entity.

Its presence created a rule we had to document explicitly: "IsSeeded must never appear on any DTO or API response."

That rule exists because IsSeeded is in the wrong place. If it lived in the infrastructure layer where it belongs, the rule would be unnecessary. The property couldn't leak to the API because the domain entity wouldn't have it.

The documented rule was a symptom. The misplaced property was the disease.

Problem 3: The Archive Method Doesn't Enforce Its Own Invariant

public void Archive()
{
    IsArchived = true;
    ArchivedAt = DateTime.UtcNow;
    UpdatedAt = DateTime.UtcNow;
}

Nothing stops you from calling Archive() on an already-archived flag. Nothing stops you from calling SetEnabled(true) on an archived flag. Archived is supposed to be a terminal state — once a flag is archived, it's frozen. But the entity doesn't enforce that.

The fix is straightforward: a guard clause at the top of every mutating method, throwing a domain exception if the flag is already archived.

public void Archive()
{
    if (IsArchived)
        throw new FlagDomainException("Cannot archive a flag that is already archived.");

    IsArchived = true;
    ArchivedAt = DateTime.UtcNow;
    UpdatedAt = DateTime.UtcNow;
}

Note: FlagDomainException is not ArgumentException or InvalidOperationException. It's a domain exception — a type that lives in the domain layer and speaks the language of business rules. The distinction matters when you're debugging at 2am.

Problem 4: The API Surface Is Confusing

Flag exposes three overlapping methods for state changes:

public void SetEnabled(bool enabled) { ... }
public void UpdateStrategy(RolloutStrategy strategyType, string? strategyConfig) { ... }
public void Update(bool isEnabled, RolloutStrategy strategyType, string? strategyConfig) { ... }

Update() does what the other two do together, atomically. So you can change enabled state and strategy either as one operation or as two separate calls. There's no domain rule telling you which to use or when.

This is what DDD practitioners call API confusion — the entity is offering multiple paths to the same state change with no clear intent. The caller has to make an architectural decision that the domain should be making.

The right approach is to separate by concern, not by field. Name changes are a distinct business operation. Rollout configuration changes are another. You don't need three methods covering overlapping ground.

Problem 5: The Big One — The Wrong Aggregate Boundary

This was the finding that surprised me most.

Flag in Banderas looks like this:

public EnvironmentType Environment { get; private set; }
public bool IsEnabled { get; private set; }
public RolloutStrategy StrategyType { get; private set; }

One flag. One environment. One strategy. If you want the same flag in both Production and Staging, you need two rows in the database — two separate Flag entities that happen to share a name.

That's not a flag with two environments. That's two flags.

Compare that to how another feature flag domain entity structures a flag in their API:

{
  "name": "Alternate product page",
  "kind": "boolean",
  "variations": [
    { "value": true,  "name": "true" },
    { "value": false, "name": "false" }
  ],
  "environments": {
    "production": {
      "on": true,
      "rules": [...],
      "fallthrough": { "rollout": { ... } }
    },
    "staging": {
      "on": false,
      "rules": [...],
      "fallthrough": { "variation": 1 }
    }
  }
}

The flag is a definition — name, variations, metadata. The behavior of that flag is environment-specific configuration sitting alongside it. One flag entity, multiple environment configurations. Same concept in Production and Staging, completely independent behavior in each.

In Banderas, a Flag is an environment. In the example above, a flag has environment configurations.

Fixing the Aggregate Boundary

The DDD solution is to split Flag into two distinct aggregates:

Flag — pure definition:

public class Flag
{
    public Guid Id { get; private set; }
    public string Name { get; private set; }
    public string? Description { get; private set; }
    public IReadOnlyList<string> Tags { get; private set; }
    public IReadOnlyList<Variation> Variations { get; private set; }
    public DateTime CreatedAt { get; private set; }
    public DateTime UpdatedAt { get; private set; }
}

FlagEnvironmentConfig — per-environment behavior:

public class FlagEnvironmentConfig
{
    public Guid Id { get; private set; }
    public Guid FlagId { get; private set; }   // reference by ID only
    public EnvironmentType Environment { get; private set; }
    public bool IsEnabled { get; private set; }
    public bool IsArchived { get; private set; }
    public IReadOnlyList<TargetingRule> Rules { get; private set; }
    public Fallthrough Fallthrough { get; private set; }
    public DateTime? ArchivedAt { get; private set; }
}

Notice FlagId is a Guid, not a Flag navigation property. In DDD, aggregates reference each other by ID only — never by object reference. This enforces the boundary. FlagEnvironmentConfig knows a Flag exists, but can't reach across the boundary and mutate it.

These two aggregates also get their own repositories: IBanderasRepository for flags, IFlagEnvironmentConfigRepository for environment configs. Independent persistence, independent consistency boundaries.

Why the Enum Is Also the Problem

Adding a new strategy type in Banderas today means:

Add a value to the RolloutStrategy enum
Write a new strategy class
Update the deserializer to handle the new StrategyConfig shape
Hope nothing silently breaks

The enum is the coupling. Every new strategy requires touching the domain model.

One way to avoid this is by making rules data, not code. Their rules array holds targeting conditions — clauses like attribute: "groups", op: "in", values: ["Top Customers"]. Adding a new targeting capability means adding a new clause operator, not modifying the core flag entity.

Banderas isn't there yet. But it's the right direction — and it starts with replacing the rigid StrategyConfig string with proper typed Value Objects and eventually moving toward a rules-based evaluation model.

Lessons Learned — DDD Edition

If you take nothing else from this post, take these:

1. Make illegal states unrepresentable.
If bad data can be constructed, it will be. Design your types so that invalid state literally cannot exist. Value Objects are the tool for this — they validate at construction and are immutable after that.

2. A documented workaround is a symptom.
Every time you write a rule like "this field must never appear in the API response," ask yourself why the field is there at all. The rule is usually telling you something is in the wrong layer.

3. Aggregates are about consistency boundaries, not object containment.
Two things belong in the same aggregate only if they must coordinate to stay consistent. If they're independent, make them separate aggregates. Forcing them together adds coupling with no benefit.

4. Aggregates reference each other by ID only.
Never hold a navigation reference across an aggregate boundary. A Guid is a reference. An object reference is a dependency.

5. Reference production systems.
Looking at how others model a flag didn't give me the answer — it gave me the right questions. Why does their flag not have an EnvironmentType? Why is IsEnabled nested under environment config? Good systems teach you what problems look like when they're solved.

6. Refactor the model before the codebase grows.
Every week you wait, the rigid model grows more calluses — more code that works around the problem instead of solving it. The right time to fix the domain model is before the next phase, not after.

If you're building something on .NET and working through similar DDD questions, I'd genuinely love to hear how you're approaching it. Drop a comment or find me on LinkedIn.

The AI Hype Cycle Is Lying to You About What to Learn

Jose Rodriguez Marrero — Thu, 16 Apr 2026 23:01:35 +0000

Written by a human
Proofread and diagram by Claude 4.7

I've been back in the code for a few months after some time away dealing with family medical stuff, and I'll be honest — the landscape looks different.

Every other post on my feed is telling me the same thing: fundamentals are dead, orchestration is the new skill, learn to prompt or get left behind. And I almost bought it. I'm the exact demographic these posts are aimed at — someone returning to the industry, a little anxious about whether my skills are still relevant, wondering if I should pivot.

Then I sat down and actually thought about it. Here's what I came up with.

The thing nobody's saying out loud

AI has collapsed the cost of producing code. It has not collapsed the cost of producing correct systems. Those are different problems.

When someone brags about shipping a SaaS in a weekend with an AI agent, what they usually built is code that works on the happy path. What they didn't build is a schema that won't paint them into a corner in 18 months, or a domain model that survives contact with a real business rule, or an API that degrades gracefully under load.

AI is very good at producing code that looks right to someone who doesn't already know what right looks like. That's the part that matters. If you can't read the output critically, you're not orchestrating — you're gambling with extra steps.

The asymmetry the hype cycle misses

Here's the part that actually changed how I'm thinking about my career:

Orchestration knowledge depreciates. Engineering knowledge compounds.

The specific techniques for prompting Claude today will be partially obsolete in a year. The multi-agent pattern that feels clever right now (Architect → Engineer → Reviewer) will either get absorbed into the tools as a default, or replaced by something better. Every six months, the playbook gets partially rewritten. You're running on a treadmill.

Deep engineering doesn't work that way. The reason IUnitOfWork exists today is the same reason it existed in 2008 and will exist in 2035 — it's about coordinating changes across aggregates in a single transactional boundary. Fowler wrote about it in 2002. It still applies. The pattern survives because the underlying problem survives.

Here's how I've been picturing it:
Knowledge value over time
Engineering depth
Value ╱
│ ╱
│ ╱ AI orchestration
│ ╱ ╱‾‾╲ ╱‾‾╲ ╱‾‾
│ ╱ ╱ ╲╱ ╲_╱
│╱_______╱
└─────────────────────────────── Time
↑ ↑ ↑
Tool v1 Tool v2 Tool v3
(reset) (reset) (reset)
Every tool generation forces the orchestrator to partially reset. The engineer keeps stacking.

The engineer who invested in fundamentals five years ago can pick up today's AI workflow in a month. The AI-native dev who skipped the fundamentals can't acquire five years of systems thinking in a month. Or a year.

Why this narrative is being pushed so hard

It's worth asking who benefits from "you don't need the fundamentals anymore."

Tool vendors selling the shortcut
Bootcamps pivoting their curriculum to "AI engineer" tracks
Influencers selling courses to people who are anxious about being left behind

The people actually hiring at good companies are telling a different story. They're raising the bar on fundamentals, because "can produce code" is now table stakes. What separates candidates is whether they can evaluate code, design systems, and make judgment calls an AI can't make for them.

So what am I actually doing about it

I'm not anti-AI. I use Claude every day. I'm building a multi-agent spec-driven pipeline for a side project right now. The tools are real and the leverage is real.

But I'm using them as a force multiplier on top of depth, not a substitute for it. My Feature Flag API in .NET isn't a portfolio prop — it's a lab where I'm actually working through DDD, Clean Architecture, and the patterns that don't depreciate.

The test I'm using for whether I actually understand something: can I explain it simply, with a diagram, to a stranger on the internet?

That's why this post exists.

Building a Feature Flag API in .NET as I work through these ideas. Follow along if you're also trying to figure out what to actually learn in 2026.

From Vibe Coding to Real Engineering: Why the Strategy Pattern Matters

Jose Rodriguez Marrero — Mon, 06 Apr 2026 18:08:49 +0000

There’s a new kind of developer emerging.

You’ve probably felt it yourself.

You open your editor, describe what you want, and code appears. APIs scaffold themselves. Business logic materializes. Entire features come together in minutes. It feels like magic.

This is what people are calling vibe coding.

And to be clear, it’s not a bad thing.

Vibe coding is incredible for:

prototyping ideas quickly
exploring new domains
getting unstuck

But here’s the catch:

Vibe coding optimizes for speed of creation.
Engineering optimizes for survivability over time.

And that’s where design patterns quietly step in.

The Problem You Don’t Notice at First

Let’s say you’re building a payment system.

You prompt your AI:

“Create a payment processor that supports credit card, PayPal, and crypto.”

And you get something like this:

public class PaymentProcessor
{
    public void ProcessPayment(string type, decimal amount)
    {
        if (type == "CreditCard")
        {
            // credit card logic
        }
        else if (type == "PayPal")
        {
            // PayPal logic
        }
        else if (type == "Crypto")
        {
            // crypto logic
        }
    }
}

It works. It’s fast. It’s clean enough.

Until…

You add Apple Pay
Then Google Pay
Then region-specific providers
Then fraud rules
Then retry policies

Suddenly that method becomes a branching maze.

And every change feels risky.

The Smell

This is the moment where good engineers pause and ask:

“What is changing in this system?”

In this case:

payment methods are changing
payment logic varies per method

That’s your signal.

Enter the Strategy Pattern

Instead of stuffing all behavior into one class, you pull the variation out.

You define a contract:

public interface IPaymentStrategy
{
    void Process(decimal amount);
}

Then implement each behavior independently:

public class CreditCardPayment : IPaymentStrategy
{
    public void Process(decimal amount) { /* ... */ }
}

public class PayPalPayment : IPaymentStrategy
{
    public void Process(decimal amount) { /* ... */ }
}

public class CryptoPayment : IPaymentStrategy
{
    public void Process(decimal amount) { /* ... */ }
}

And your processor becomes:

public class PaymentProcessor
{
    private IPaymentStrategy _strategy;

    public void SetStrategy(IPaymentStrategy strategy)
    {
        _strategy = strategy;
    }

    public void ProcessPayment(decimal amount)
    {
        _strategy.Process(amount);
    }
}

What Just Changed?

This is subtle, but powerful.

Before:

The processor decided how payments were handled
Adding new behavior meant modifying existing code

After:

The processor delegates how to a strategy
New behavior is added by introducing new classes

No existing code needs to change.

Why This Matters (Especially in the AI Era)

AI is very good at generating solutions.

But it doesn’t always optimize for:

long-term maintainability
extensibility
fault isolation
architectural clarity

That’s your job.

The Strategy Pattern gives you:

1. Isolation of Change

Each payment method lives in its own class.

A bug in crypto payments doesn’t ripple into credit card logic.

2. Open for Extension, Closed for Modification

You don’t rewrite your system to grow it.

You extend it.

That’s the difference between:

a system that evolves
and one that eventually collapses under its own weight

3. Runtime Flexibility

You can swap behavior dynamically:

processor.SetStrategy(new PayPalPayment());

Or more realistically:

var strategy = resolver.Resolve(paymentType);
processor.SetStrategy(strategy);

Now behavior is driven by configuration, not conditionals.

The Bigger Shift

The Strategy Pattern isn’t really about interfaces.

It’s about this mindset:

“My objects shouldn’t own behavior that changes frequently.”

Instead:

“They should delegate that behavior to something interchangeable.”

That’s how you build systems that last.

Vibe Coding vs Engineering

Vibe coding gets you to:

“It works.”

Design patterns get you to:

“It will keep working when everything changes.”

You don’t need patterns for every piece of code.

But when you see:

growing conditionals
branching logic
behavior that varies by type

That’s your cue.

One Line to Take With You

Strategy lets you change behavior without changing the code that uses it.

If you internalize that, you’ll start seeing it everywhere.

And that’s when you stop just generating code…

…and start designing systems.

Written by Jose
Proofread/Edited by ChatGPT 5.4

My Dev Environment Hated Me (And How I Fixed It)

Jose Rodriguez Marrero — Sun, 22 Mar 2026 23:22:33 +0000

A returning developer's battle with devcontainers, Docker image tags, and OAuth callbacks that ghost you like a bad Tinder date.

I'm back. After a few months away to deal with a family medical situation (more on that at the end), I've returned to the industry with a mission: build portfolio-worthy, production-grade projects and sharpen my .NET skills back to a competitive level.

My first project? A Feature Flag Service — a clean architecture .NET API that evaluates feature flags deterministically using rollout strategies like percentage-based rollouts and role-based targeting. Think LaunchDarkly, but built by me, from scratch, with a focus on solid engineering principles.

Before writing a single line of business logic, I had to do something deceptively simple: set up my dev environment.

Two hours later, I had four separate errors and a story worth writing about.

The Setup

The plan was clean and modern:

Devcontainer for a reproducible, containerized development environment
Claude Code inside the container for AI-assisted development
.NET 10 because why not use the latest?
VSCode Dev Containers extension to tie it all together

Here's what my devcontainer.json looked like going in:

{
  "name": "Feature Flag Service",
  "image": "mcr.microsoft.com/devcontainers/dotnet:1-10.0-bookworm",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {},
    "ghcr.io/devcontainers/features/node:1": { "version": "lts" }
  },
  "forwardPorts": [5000, 5001],
  "postCreateCommand": "dotnet restore && dotnet tool restore"
}

Looks reasonable, right? Narrator: It was not reasonable.

Bug #1 — The Image That Doesn't Exist

Error response from daemon: failed to resolve reference 
"mcr.microsoft.com/devcontainers/dotnet:1-10.0-bookworm": not found

Right out of the gate. Docker couldn't pull the image because the tag 1-10.0-bookworm simply does not exist.

Here's the thing about Docker image tags — they're not automatically generated for every version of every framework. The mcr.microsoft.com/devcontainers/dotnet image only has published tags up to 8.0 and 9.0. No 10.0 yet.

But there's a second twist: .NET 10 dropped Debian (Bookworm) entirely. Starting with .NET 10, Microsoft switched the default base OS to Ubuntu. So even if the tag existed, -bookworm would be wrong.

The fix: Drop down to the latest available devcontainer image:

"image": "mcr.microsoft.com/devcontainers/dotnet:9.0"

Lesson: Always verify Docker image tags exist before assuming they do. The pattern <language>:<version>-<os> isn't guaranteed — check the registry.

Bug #2 — The OAuth Callback That Ghosted Me (Main Event)

This one is the real star of today's post. Container built successfully. Claude Code installed. Time to log in.

claude auth login --claudeai

Browser opens. I authenticate. I'm redirected back to VSCode and... nothing. The terminal just hangs. Waiting. Forever.

Eventually:

Failed to retrieve auth status after login

What's actually happening here is a fascinating networking problem.

The Root Cause

When you run claude auth login, Claude Code spins up a localhost callback server on a random ephemeral port. The OAuth flow works like this:

Claude Code starts listening on localhost:RANDOM_PORT
Your browser opens claude.ai/oauth/authorize
You authenticate in the browser
The browser is redirected back to localhost:RANDOM_PORT/callback
Claude Code receives the token and stores it

The problem? You're inside a container. The browser lives on your host machine. The callback server lives inside the container. That random port is never forwarded, so the callback from the browser never arrives. Claude Code sits there waiting for a knock on a door that nobody can reach.

HOST                          DEVCONTAINER
┌──────────────┐              ┌─────────────────────┐
│   Browser    │──callback──X─▶│  claude auth login  │
│              │  :RANDOM      │  (listening on      │
└──────────────┘  NOT FORWARDED│   RANDOM port)      │
                               └─────────────────────┘

The Fix — Bind Mount Your Host Credentials

The cleanest solution: log in on your host machine once, then mount your credentials into the container.

Claude Code stores OAuth tokens in two places on your filesystem:

~/.claude/ — credentials, config, session data
~/.claude.json — onboarding state (easy to miss this one!)

Update your devcontainer.json mounts:

"mounts": [
  "source=${localEnv:HOME}/.claude,target=/home/vscode/.claude,type=bind",
  "source=${localEnv:HOME}/.claude.json,target=/home/vscode/.claude.json,type=bind"
]

Then on your host machine (not inside the container):

claude auth login

Complete the OAuth flow normally. Rebuild the container. Done — Claude Code inside the container picks up your credentials automatically, no login required.

Lesson: OAuth callback flows assume the browser and the listening server are on the same machine. In containerized environments, that assumption breaks. Bind mounts are your friend.

Bug #3 — `postCreateCommand` Needs a Map

postCreateCommand failed with exit code 1

Vague. Unhelpful. Classic.

Running the commands manually revealed the culprit:

dotnet restore
# error: Specify a project or solution file.

The container doesn't automatically know which solution to restore. A simple fix:

"postCreateCommand": "dotnet restore FeatureFlagService.sln && dotnet tool restore"

Lesson: Be explicit in automation. Commands that work fine interactively (where you're already in context) can fail in scripts because that context doesn't exist.

Bug #4 — The SDK vs. Target Framework Mismatch

error NETSDK1045: The current .NET SDK does not support targeting .NET 10.0.
Either target .NET 9.0 or lower, or use a version of the .NET SDK that supports .NET 10.0.

Remember how we switched to the .NET 9 devcontainer image? Right. The SDK is .NET 9. The project targets .NET 10. They don't agree.

Rather than installing a custom SDK (more complexity, more maintenance), I downgraded all project files to target net9.0:

find . -name "*.csproj" | xargs sed -i \
  's/<TargetFramework>net10.0<\/TargetFramework>/<TargetFramework>net9.0<\/TargetFramework>/g'

One command. All five .csproj files updated. Verified with:

grep -r "TargetFramework" --include="*.csproj"

Lesson: Your container image's SDK version and your project's target framework must align. When they don't, decide which one you're willing to move — usually it's easier to adjust the project than rebuild the image.

The Final `devcontainer.json`

Here's where we landed after all four fixes:

{
  "name": "Feature Flag Service",
  "image": "mcr.microsoft.com/devcontainers/dotnet:9.0",

  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {},
    "ghcr.io/devcontainers/features/node:1": { "version": "lts" }
  },

  "forwardPorts": [5000, 5001],
  "portsAttributes": {
    "5000": { "label": "HTTP", "onAutoForward": "notify" },
    "5001": { "label": "HTTPS", "onAutoForward": "notify" }
  },

  "mounts": [
    "source=${localEnv:HOME}/.claude,target=/home/vscode/.claude,type=bind",
    "source=${localEnv:HOME}/.claude.json,target=/home/vscode/.claude.json,type=bind"
  ],

  "containerEnv": {
    "CLAUDE_CONFIG_DIR": "/home/vscode/.claude",
    "ASPNETCORE_ENVIRONMENT": "Development"
  },

  "remoteUser": "vscode",
  "containerUser": "vscode",

  "postCreateCommand": "dotnet restore FeatureFlagService.sln && dotnet tool restore",
  "postStartCommand": "git config --global --add safe.directory ${containerWorkspaceFolder}",

  "customizations": {
    "vscode": {
      "extensions": [
        "ms-dotnettools.csharp",
        "ms-dotnettools.csdevkit",
        "humao.rest-client",
        "eamodio.gitlens",
        "editorconfig.editorconfig",
        "streetsidesoftware.code-spell-checker"
      ],
      "settings": {
        "editor.formatOnSave": true,
        "editor.tabSize": 4,
        "files.eol": "\n",
        "dotnet.defaultSolution": "FeatureFlagService.sln"
      }
    }
  }
}

Wrapping Up

Four bugs. One working dev environment. Two hours I'll never get back — but also two hours that gave me a much better understanding of how Docker networking, OAuth flows, and devcontainer configuration actually work under the hood.

The Feature Flag Service itself is still ahead of me. Clean Architecture layers to wire up, a deterministic hashing strategy to implement, unit tests to write. But the foundation is solid, the tooling is in place, and Claude Code is authenticated and ready to pair program.

Next post: getting into the actual code — implementing the evaluation engine and the strategy pattern at the heart of this thing.

A note on the comeback: I stepped away from software development for a couple of years to deal with a family medical situation. That chapter is now closed, and I'm back — sharper, more intentional, and honestly more motivated than ever. If you're a developer who's taken time away for life reasons, this blog is partly for you. It's possible to come back. Let's build.

Tags: #dotnet #devcontainers #docker #claudecode #webdev #programming #cleanarchitecture #debugging

🧠 Backing Fields in C#: What They Are and Why You Should Care

Jose Rodriguez Marrero — Sat, 31 May 2025 18:11:22 +0000

As a C# developer, you've probably written something like this:

public string Name { get; set; }

Short. Sweet. Gets the job done.

But what if you need to sneak in a little logic? What if you want to say, “Hey! You can't set Age to -200!”?

That’s when it’s time to meet your new(ish) best friend: backing fields.

🔙 Wait… What’s a Backing Field?

A backing field is just a private variable that stores the actual value for a property.

Think of it like this:

// Backing field
private string _email;

// Property using that field
public string Email
{
    get => _email;
    set => _email = value;
}

You're basically wrapping that private _email in a nice public interface (Email) so other parts of your code can use it safely.

✨ Auto-Properties: The Lazy Magic

When you write this:

public string Email { get; set; }

The compiler quietly creates something like:

private string _email; // 👻 invisible to you!

public string Email
{
    get => _email;
    set => _email = value;
}

No muss, no fuss — but also no customization. You can’t sneak in any logic. It’s like ordering black coffee when you really need a vanilla oat milk latte with light foam and a shot of espresso (a.k.a. validation).

💡 So When Do You Need a Backing Field?

Glad you asked. Here are a few classic cases:

1. Validation

charp

private int _age;

public int Age
{
    get => _age;
    set => _age = value < 0 ? 0 : value; // No negative ages allowed!
}

2. Logging or Side Effects

private string _name;

public string Name
{
    get => _name;
    set
    {
        Console.WriteLine($"Changing name from {_name} to {value}");
        _name = value;
    }
}

3. Transforming Input

Here’s a real-world example from a product filter class I'm currently building:

private List<string> _brands = [];

public List<string> Brands
{
    get => _brands;
    set => _brands = [.. value.SelectMany(p => p.Split(',', StringSplitOptions.RemoveEmptyEntries))];
}

Now, instead of forcing users to send ["Nike", "Adidas"], they can just send:

new List<string> { "Nike,Adidas", "Puma" }

And you’ll still end up with:

["Nike", "Adidas", "Puma"]

That's right, homeys!!✨

Quick Comparison

Feature	Auto-Property	Backing Field
Super simple	✅ Yup	❌ More typing
Add logic or validation	❌ Nope	✅ Totally
Trigger side effects	❌ Not a chance	✅ All day
Transform data on set	❌ Can't do it	✅ Yes, chef

🧵 Wrap-up

Backing fields are like the secret sauce behind well-behaved properties. Sure, auto-properties are great for the everyday stuff, but when you need more control, don’t be afraid to write things out manually.

Whether you're validating data, formatting input, or just want to sneak a Console.WriteLine in there — backing fields have your back (literally).

What’s your favorite use case for a backing field? Ever tried doing too much with an auto-property and had it backfire? Drop a comment — I’d love to hear your war stories.

Static + Generics = Trouble? Why Your C# Code Smells and How to Clean It Up

Jose Rodriguez Marrero — Wed, 28 May 2025 02:53:45 +0000

So there I was… writing some C# code for my, minding my own business, when bam — the compiler drops this wisdom on me:

⚠️ CA1000: Do not declare static members on generic types

And I’m like...

“Okay compiler, but can you explain that like I’m five?”

Let’s break it down.

🍱 Static + Generics: What’s Actually Going On?

You might write something like this:

public class SnackBox<T>
{
    public static int SnackCount;
}

Seems harmless. But if you use it like this:

SnackBox<string>.SnackCount = 5;
SnackBox<int>.SnackCount = 10;

Console.WriteLine(SnackBox<string>.SnackCount); // 5
Console.WriteLine(SnackBox<int>.SnackCount);    // 10

You suddenly realize: 😱 Each version of T gets its own static member.
So now you’ve got dozens of mini snack boxes floating around in memory — each hoarding their own SnackCount.

🧽 What This Has To Do With Real Code

Let’s say you’re writing a helper to apply specs to a query:

public static class SpecificationEvaluator<T>
    where T : BaseEntity
{
    public static IQueryable<T> GetQuery(IQueryable<T> query, ISpecification<T> spec)
    {
        if (spec.Criteria != null)
        {
            query = query.Where(spec.Criteria);
        }

        return query;
    }
}

Looks fine, right?

Well, sort of. But this triggers CA1000, and for good reason:

You now have a separate static class per type — e.g., SpecificationEvaluator<Product>, SpecificationEvaluator<Order>, etc.
That increases memory usage
It’s harder to use (you have to specify the type every time)
And worst of all... the compiler is silently judging you 😬

🧹 The Fix: Static Class, Generic Method

We can clean this up by moving the generic parameter from the class to the method:

public static class SpecificationEvaluator
{
    public static IQueryable<T> GetQuery<T>(IQueryable<T> query, ISpecification<T> spec)
        where T : BaseEntity
    {
        if (spec.Criteria != null)
        {
            query = query.Where(spec.Criteria);
        }

        return query;
    }
}

Now you can call it like:

var result = SpecificationEvaluator.GetQuery(products, productSpec);

No generic class instantiations
Cleaner syntax
The compiler stops yelling 🎉

✅ TL;DR — What Did We Learn?

❌ Don’t Do This	✅ Do This Instead
`static class MyHelper<T>`	`static class MyHelper`
Static method inside generic class	Generic static method inside static class
One copy per `T`	One reusable method for all types
CA1000 warning	✨ No warning, no surprises ✨

🎯 Final Thoughts

If you've ever been confused by that CA1000 warning or wondered why your static generic utility felt “off,” you’re not alone.

Just remember:

Static classes are like toolboxes.
You don’t need a separate toolbox for every kind of screw. 🧰

Happy coding! 👨‍💻👩‍💻
Have you encountered CA1000 before? Drop a comment — I'd love to hear your story or tips!

IEnumerable vs IReadOnlyList in .NET: When Should You Use Each?

Jose Rodriguez Marrero — Fri, 23 May 2025 23:10:32 +0000

If you’re working in C# and .NET, you’ll quickly run into different collection interfaces like IEnumerable<T> and IReadOnlyList<T>. At first glance, they seem pretty similar—both let you work with a set of items in a read-only way. So when should you use each? In this post, I’ll break down the differences, show real-world use cases, and give you code samples so you know exactly when to reach for one or the other.

Quick Definitions

IEnumerable<T>

The simplest way to represent a sequence of items that you can iterate over (with foreach). It doesn’t let you access by index or get the count directly.

IReadOnlyList<T>

Represents a read-only list of items. You can access items by index and get the number of items, but you can’t change the collection.

Code Examples

Example 1: Using `IEnumerable<T>`

public IEnumerable<string> GetAllProductNames()
{
    // Could return from a database query, LINQ, etc.
    return products.Select(p => p.Name);
}

// Usage
foreach (var name in GetAllProductNames())
{
    Console.WriteLine(name);
}

When to use:

When you only need to iterate (loop) over the items.
When the results might be streamed, generated, or filtered on-the-fly.
You don’t need to know the exact number of items or their positions.

Example 2: Using `IReadOnlyList<T>`

public IReadOnlyList<Product> GetFeaturedProducts()
{
    // Return a fixed, materialized list
    return featuredProducts.AsReadOnly();
}

// Usage
for (int i = 0; i < GetFeaturedProducts().Count; i++)
{
    var product = GetFeaturedProducts()[i];
    Console.WriteLine($"{i}: {product.Name}");
}

When to use:

When you need to access items by their index (e.g., list[0]).
When you want to expose the count (list.Count).
When you want to guarantee that the collection is fixed and can’t be changed by the consumer.

Feature	IEnumerable	IReadOnlyList
Can loop with foreach	✅	✅
Access by index	❌	✅
Get count	❌	✅
Immutable/read-only	❌ (just iterates)	✅ (read-only contract)
Deferred execution	✅ (often)	❌ (usually materialized)

How to Decide Which to Use

Use IEnumerable<T> when you want to keep things simple, just need to loop, or want to allow streaming of results.
Use IReadOnlyList<T> when you want the safety and convenience of a fixed, read-only list that exposes both count and index-based access.

Real-World Examples

Repository Pattern (Read-only)

Use IEnumerable<T> for large datasets you want to stream or filter on demand.
Use IReadOnlyList<T> for methods that return a set of results you want to lock down (like the top 10 products).

API Response

Use IReadOnlyList<T> to return a clear, fixed collection (helps with serialization and contracts).
Use IEnumerable<T> internally, especially when chaining LINQ queries.

Quick Tip for Juniors

If you want to let others loop through your data, use IEnumerable<T>.
If you want to let others see how many items you have and access by index—but not modify anything—use IReadOnlyList<T>.

Got questions or want more real-world .NET tips? Drop a comment below!

Taming Your First Docker Build in 5 Minutes

Jose Rodriguez Marrero — Fri, 23 May 2025 16:53:29 +0000

Ever wished your app “just worked” on every machine? Docker gives you consistent, isolated environments—no more “it works on my machine” drama. In this hands-on guide, you’ll go from zero to a running container in five minutes flat.

🛠 Prerequisites

Docker Desktop (macOS/Windows) or Docker Engine (Linux) installed
A simple sample app. We’ll use a minimal ASP.NET Core “Hello World” API, but you can swap in Node.js or static files.

# Check you have Docker:
docker --version

📄 Crafting Your Dockerfile

Create a file named Dockerfile in your project root:

# 1. Base runtime image
FROM mcr.microsoft.com/dotnet/aspnet:7.0 AS base
WORKDIR /app
EXPOSE 80

# 2. Build stage
FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build
WORKDIR /src
COPY *.csproj .
RUN dotnet restore
COPY . .
RUN dotnet publish -c Release -o /app/publish

# 3. Final image
FROM base AS final
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MyApp.dll"]

Tip: Replace MyApp.dll with your project’s DLL name.

🏗 Building the Image

Run:

docker build -t infraforge-dev-hello .

-t infraforge-dev-hello tags your image
. tells Docker to use the current folder as the build context
You’ll see logs of each layer being built and cached

▶️ Running & Testing

Start your container and map port 80 → 8080:

docker run --rm -p 8080:80 infraforge-dev-hello

--rm cleans up the container when you stop it
Navigate to http://localhost:8080 or run:

curl http://localhost:8080

✨ Quick Wins & Optimizations

.dockerignore

bin/
obj/
.vs/

Layer caching: put infrequently changing instructions (e.g., RUN dotnet restore) early.
Multi-stage builds: keeps final image slim—our example already uses one.

🐞 Troubleshooting Tips

Verbose output:

docker build --progress=plain .

Inspect broken images:

docker run --rm -it infraforge-dev-hello /bin/bash

Common pitfalls: wrong file paths, missing dependencies, port mismatches.

🐳 Deep Dive: Understanding the Container Lifecycle

Docker containers transition through well-defined states. Knowing these helps you manage, debug, and automate effectively:

Created: Container exists, but not running.

docker ps -a
# STATUS: Created

Running: Main process is executing.

docker ps
# STATUS: Up X seconds

Paused: Process temporarily frozen.

docker pause <container_id>
docker unpause <container_id>

Exited: Process finished or crashed.

docker ps -a
# STATUS: Exited (1) X seconds ago

Removed: Container deleted.

docker rm <container_id>

Common Lifecycle Commands

# List all containers (running + stopped)
docker ps -a

# Start a stopped container
docker start <container_id>

# Stop a running container (graceful shutdown)
docker stop <container_id>

# Force-restart
docker restart <container_id>

# Remove
docker rm <container_id>

Why it matters:

CI/CD automation: detect “Exited” states to trigger alerts or restarts.
Resource cleanup: proactively remove unused containers to free disk space.
Debugging: start a crashed container interactively to inspect logs or shell in.

📚 Next Steps

Scan for vulnerabilities:

docker scan infraforge-dev-hello

Push to a registry:

docker tag SOURCE_IMAGE TARGET_IMAGE:TAG
# example: docker tag infraforge-dev-hello infraforge-dev/infraforge-dev-hello:v1.0
docker push infraforg-dev/infraforge-dev-hello:v1.0

Automate with GitHub Actions: integrate docker build & docker push on every PR.

Additional Resources:

Docker Official Docs – Get Started & Dockerfile Best Practices
The definitive guide from Docker: an end-to-end “Get Started” tutorial plus the full Dockerfile reference and best-practices guide to optimize builds.
https://docs.docker.com/get-started/
https://docs.docker.com/engine/reference/builder/
Docker Curriculum by Prakhar Srivastav
A free, community-driven, step-by-step walkthrough of Docker fundamentals, from images and containers to multi-stage builds and networking.
https://docker-curriculum.com/
Play with Docker
An in-browser Docker playground—spin up real Docker hosts and containers without installing anything. Great for experimenting with Dockerfiles, commands, and networking.
https://labs.play-with-docker.com/

That’s it—five minutes to your first Docker build, plus a clear view of what happens under the hood. Drop a comment if you hit any snags or have tips of your own!

Jose (@infraforge-dev)

From Code to Purpose: Kickoff at InfraForge-dev

Jose Rodriguez Marrero — Fri, 23 May 2025 15:45:08 +0000

👋 Hello Dev.to — I’m Jose!

Ever wonder how many CI/CD pipelines it takes to deploy an e-commerce API? (Spoiler: less than you think, but more than one!)

I’m Jose, a .NET backend & DevOps engineer on a mission to forge purposeful solutions—not just code and configs, but the clear reasons behind each decision. After a year of deep dives into cloud architecture, containerization, and front-end wizardry (Angular 18 + TypeScript, I see you!), I’m finally sharing my experiments in real time.

🔨 What I’m Working On

InfraForge E-Commerce API: An ASP.NET Core backend serving thousands of products in under 100 ms.
Pipeline Playground: GitHub Actions → Docker → AWS Elastic Beanstalk (and yes, I’ll show you how to tame that YAML monster).
Frontend Fun: Angular 18 UI that drinks from my API’s firehose—spoiler: caching matters!

🚀 Why You’ll Stick Around

I’m all about demystifying the “magic” of DevOps and API design. Expect:

Deep-dive posts on performance tweaks, security hardening, and real-world trade-offs.
Code snippets you can copy/paste (and modify).
Honest “what went wrong” behind the scenes.

So hit that 🌟, follow along, and drop a comment to say hi! Next up: “Taming Your First Docker Build in 5 Minutes.”

— Jose (@infraforge-dev)