I ❤️ .NET

Table of Contents

1. What we gonna do?
2. Why we gonna do?
3. How we gonna do?
4. Summary

What we gonna do?

Not all parts of your system deserve equal investment. Some features define your competitive advantage, while others simply keep the lights on. In this article, we'll explore how to classify your system into Core Domains, Supporting Domains, and Generic Domains—and why this classification is critical for making smart architectural decisions.

Understanding this distinction helps you answer crucial questions: Where should you invest your best developers? Which areas deserve deep domain modeling with full DDD? Which features can you buy off-the-shelf instead of building from scratch? Making these decisions correctly can mean the difference between building a sustainable competitive advantage and wasting resources on commoditized functionality.

We'll examine a practical decision framework that helps you classify each subdomain in your system, along with specific recommendations for investment levels, staffing, quality expectations, and architectural approaches for each category.

Why we gonna do?

The Investment Problem

Every software project has multiple competing concerns. Consider a typical digital license management system that needs:

• License activation logic
• Payment processing via Stripe
• Email notifications
• User authentication via Single Sign-On
• Audit logging
• File storage using cloud infrastructure
• Analytics dashboards

Teams face a critical challenge: they can't invest equally in all these areas. Resources are limited—budget, time, and skilled developers are finite. The key question becomes: How do we decide where to focus our best talent and deepest effort?

Making this decision poorly has serious consequences:

• Misallocated Resources: Spending senior developers' time on commodity features like email notifications wastes expertise
• Weak Core: Under-investing in your competitive differentiator allows competitors to surpass you
• Over-Engineering: Applying complex DDD patterns to simple generic features creates unnecessary maintenance burden
• Build vs. Buy Mistakes: Building features from scratch that you could integrate for a fraction of the cost

Why Classification Matters

Classifying your system into Core, Supporting, and Generic domains provides a clear framework for making these investment decisions. This classification helps you:

Align Investment with Value: Your most valuable features get your best resources. Your competitive edge receives maximum investment, while commodity features receive minimal effort.

Guide Architectural Decisions: Core domains deserve full DDD with rich modeling. Supporting domains use pragmatic patterns. Generic domains get integrated third-party solutions.

Optimize Team Structure: Senior developers work on core domains where their expertise matters most. Junior developers handle integration of generic features where complexity is lower.

Set Quality Expectations: Operational excellence for core domains, "good enough" for supporting domains, and reliable integration for generic domains.

Inform Build vs. Buy: Generic domains are prime candidates for third-party services or open-source solutions, freeing your team to focus on what makes you unique.

How we gonna do?

Step 1: Understand the Three Domain Types

Let's examine each domain classification in detail, including characteristics, investment strategy, and practical examples.

Core Domain - Your Competitive Advantage

The Core Domain is the heart of your business—what makes you special and differentiates you from competitors. This is where innovation happens and where your business wins or loses.

Characteristics:

• Competitive Advantage: This is what makes you unique in the market
• Constantly Evolving: Frequent changes based on market demands and innovation
• Complex Business Rules: Intricate logic that embodies domain expertise
• High Business Value: Direct impact on revenue, customer satisfaction, or market position

Investment Strategy:

• Investment Level: Maximum—this is your main focus
• Staffing: Assign your best, most experienced developers
• Quality: Aim for operational excellence with comprehensive testing and monitoring
• Approach: Apply full Domain-Driven Design with strategic and tactical patterns

Examples in a Digital Licensing System:

• License activation and compliance verification logic
• Flexible licensing models (subscription, perpetual, usage-based)
• Hardware fingerprinting and device management
• License transfer and deactivation workflows

// Core Domain: Rich model with complex business rules
public class License
{
    private readonly List<Activation> _activations = new();
    private readonly LicensePolicy _policy;
    private LicenseStatus _status;

    public void Activate(HardwareFingerprint fingerprint)
    {
        // Complex business rules that define competitive advantage
        if (_status == LicenseStatus.Expired)
        {
            throw new LicenseExpiredException(
                "Cannot activate expired license");
        }

        if (_status == LicenseStatus.Suspended)
        {
            throw new LicenseSuspendedException(
                "Cannot activate suspended license");
        }

        if (!_policy.AllowsAdditionalActivation(_activations.Count))
        {
            throw new ActivationLimitExceededException(
                $"License allows maximum {_policy.MaxActivations} activations");
        }

        if (_activations.Any(a => a.Fingerprint == fingerprint))
        {
            throw new DuplicateActivationException(
                "Device already activated");
        }

        var activation = new Activation(fingerprint, DateTime.UtcNow);
        _activations.Add(activation);
        _status = LicenseStatus.Active;

        // Raise domain event
        RaiseDomainEvent(new LicenseActivated(Id, fingerprint, DateTime.UtcNow));
    }

    public void Transfer(CustomerId newCustomer)
    {
        // Sophisticated transfer logic with compliance checks
        if (_policy.RestrictsTransfer)
        {
            throw new TransferNotAllowedException(
                "License policy does not allow transfer");
        }

        _activations.Clear();
        _status = LicenseStatus.PendingActivation;
        CustomerId = newCustomer;

        RaiseDomainEvent(new LicenseTransferred(Id, newCustomer, DateTime.UtcNow));
    }
}
      

Supporting Domain - Necessary but Not Differentiating

Supporting Domains enable your Core Domain to function but don't provide competitive advantage. They're important for your system's operation but aren't what makes you special.

Characteristics:

• Necessary: Required for the system to work, but not a differentiator
• Simpler than Core: Less complex business rules
• Some Custom Requirements: Can't use pure generic solutions due to specific needs
• Moderate Change Rate: Evolves occasionally but not constantly

Investment Strategy:

• Investment Level: Moderate—important but not the main focus
• Staffing: Assign competent developers who can handle the requirements
• Quality: Aim for "good enough"—reliable and functional without over-engineering
• Approach: Use simple, pragmatic patterns; selective tactical DDD where it helps

Examples in a Digital Licensing System:

• Customer portal for viewing license status
• License usage reporting and analytics
• Customer support ticketing
• Basic invoicing and receipt generation

// Supporting Domain: Simple pragmatic patterns
public class LicenseReportingService
{
    private readonly ILicenseRepository _licenseRepository;
    private readonly IReportGenerator _reportGenerator;

    public async Task<LicenseUsageReport> GenerateUsageReport(
        CustomerId customerId, 
        DateRange dateRange)
    {
        // Straightforward query and reporting logic
        var licenses = await _licenseRepository
            .GetByCustomerAsync(customerId);

        var activations = licenses
            .SelectMany(l => l.GetActivations())
            .Where(a => dateRange.Contains(a.ActivatedAt))
            .ToList();

        return new LicenseUsageReport
        {
            CustomerId = customerId,
            Period = dateRange,
            TotalLicenses = licenses.Count,
            ActiveLicenses = licenses.Count(l => l.IsActive),
            TotalActivations = activations.Count,
            UniqueDevices = activations
                .Select(a => a.HardwareFingerprint)
                .Distinct()
                .Count()
        };
    }

    public async Task<byte[]> ExportToPdf(LicenseUsageReport report)
    {
        // Delegate to third-party PDF library
        return await _reportGenerator.GeneratePdfAsync(report);
    }
}
      

Generic Domain - Commodity Functionality

Generic Domains are common across industries—features that everyone needs but no one wins by implementing. These are prime candidates for integration rather than custom development.

Characteristics:

• No Competitive Edge: Everyone has these features; they're table stakes
• Commodity Functionality: Well-understood problems with established solutions
• Stable: Requirements don't change frequently
• Interchangeable: Multiple vendors offer equivalent solutions

Investment Strategy:

• Investment Level: Minimal—just enough to integrate successfully
• Staffing: Team members who can handle configuration and API integration
• Quality: Reliable integration with established third-party services
• Approach: Integrate Software-as-a-Service or use open-source libraries

Examples in a Digital Licensing System:

• Email notifications (SendGrid, Mailgun)
• Audit logging (Elasticsearch, Splunk)
• File storage (AWS S3, Azure Blob Storage)
• User authentication (Auth0, Azure AD)
• Payment processing (Stripe, PayPal)
• Analytics dashboards (Power BI, Tableau)

// Generic Domain: Thin wrapper around third-party service
public class EmailNotificationService
{
    private readonly ISendGridClient _sendGridClient;
    private readonly IConfiguration _configuration;

    public EmailNotificationService(
        ISendGridClient sendGridClient, 
        IConfiguration configuration)
    {
        _sendGridClient = sendGridClient;
        _configuration = configuration;
    }

    public async Task SendLicenseActivatedEmailAsync(
        string recipientEmail, 
        string licenseKey)
    {
        var msg = new SendGridMessage
        {
            From = new EmailAddress(
                _configuration["Email:FromAddress"], 
                "License Management"),
            Subject = "License Activated Successfully",
            PlainTextContent = $"Your license {licenseKey} has been activated.",
            HtmlContent = $"<p>Your license <strong>{licenseKey}</strong> has been activated.</p>"
        };

        msg.AddTo(new EmailAddress(recipientEmail));

        // Delegate to third-party service
        await _sendGridClient.SendEmailAsync(msg);
    }
}

// Generic Domain: Configuration wrapper for cloud storage
public class LicenseFileStorageService
{
    private readonly BlobContainerClient _containerClient;

    public LicenseFileStorageService(BlobServiceClient blobServiceClient)
    {
        _containerClient = blobServiceClient
            .GetBlobContainerClient("license-files");
    }

    public async Task<string> UploadLicenseDocumentAsync(
        Guid licenseId, 
        Stream fileStream, 
        string fileName)
    {
        var blobClient = _containerClient.GetBlobClient(
            $"{licenseId}/{fileName}");

        await blobClient.UploadAsync(fileStream, overwrite: true);

        return blobClient.Uri.ToString();
    }
}
      

Step 2: Apply the Classification Decision Tree

Use this framework to classify each feature or subdomain:

Question 1: Does this feature differentiate your business from competitors?

• Yes: This is a Core Domain. Apply maximum investment and full DDD.
• No: Continue to Question 2.

Question 2: Does this solve a problem that's somewhat unique to your business?

• Yes: This is a Supporting Domain. Apply moderate investment and pragmatic patterns.
• No: This is a Generic Domain. Integrate third-party solutions.

Step 3: Map Your System

Let's apply this framework to a complete digital licensing system:

Step 4: Avoid Common Mistakes

Watch out for these classification pitfalls:

Mistake 1: Treating Everything as Core

Some teams apply complex DDD patterns to every feature, wasting effort on commodity functionality. Be honest about what truly differentiates your business.

Mistake 2: Under-Investing in Core

Conversely, some teams under-invest in their core domain, allowing competitors to surpass them. Your core deserves your best resources.

Mistake 3: Building Instead of Buying Generic

Building email notification systems from scratch wastes valuable development time. Use established services for generic domains.

Mistake 4: Misclassifying Supporting as Core

Just because something is important doesn't make it core. Ask whether it differentiates you—if not, it's supporting or generic.

Summary

Classifying your system into Core, Supporting, and Generic domains is essential for making smart investment decisions. Your Core Domain—where competitive advantage lives—deserves maximum investment, your best developers, and full Domain-Driven Design treatment.

Supporting Domains enable your core to function but don't differentiate you. They warrant moderate investment and pragmatic patterns that deliver reliable functionality without over-engineering. Generic Domains represent commodity features that every system needs but no one wins by building. These are prime candidates for third-party integration, freeing your team to focus on what makes you unique.

Use the classification decision tree—asking whether features differentiate your business and whether they're unique to your context—to systematically evaluate every subdomain. This framework aligns your architectural investments with business value, ensuring you build sustainable competitive advantage rather than reinventing commodity features.

Map your own system using this approach. Identify your core domain, protect it with your best resources, and simplify everything else through pragmatic patterns or integration. This discipline is what separates successful systems from over-engineered ones that waste resources on the wrong things.