I've been studying DDD and I'm currently struggling to find a way to apply the concepts in actual code. I have about 10 years of experience with N-tier, so it's very likely that the reason I'm struggling is that my mental model is too coupled to that design.

I've created an Asp.NET Web Application and I'm starting with a simple domain: a web monitoring application. Requirements:

  • The user must be able to register a new Web App to monitor. The web app has a friendly name and points to a URL;
  • The web app will periodically poll for a status (online/offline);
  • The web app will periodically poll for its current version (the web app is expected to have a "/version.html", which is a file declaring its system version in a specific markup).

My doubts concern mainly the division of responsibilities, finding the proper place for each thing (validation, business rule, etc). Below, I've written some code and added comments with questions and considerations.

Please criticize and advise. Thanks in advance!


Modeled to encapsulate all business rules.

// Encapsulates logic for creating and validating Url's.
// Based on "Unbreakable Domain Models", YouTube talk from Mathias Verraes
// See https://youtu.be/ZJ63ltuwMaE
public class Url: ValueObject
    private System.Uri _uri;

    public string Url => _uri.ToString();

    public Url(string url)
        _uri = new Uri(url, UriKind.Absolute); // Fails for a malformed URL.

// Base class for all Aggregates (root or not).
public abstract class Aggregate
    public Guid Id { get; protected set; } = Guid.NewGuid();
    public DateTime CreatedAt { get; protected set; } = DateTime.UtcNow;

public class WebApp: Aggregate
    public string Name { get; private set; }
    public Url Url { get; private set; }
    public string Version { get; private set; }
    public DateTime? VersionLatestCheck { get; private set; }
    public bool IsAlive { get; private set; }
    public DateTime? IsAliveLatestCheck { get; private set; }

    public WebApp(Guid id, string name, Url url)
        if (/* some business validation fails */)
            throw new InvalidWebAppException(); // Custom exception.

        Id = id;
        Name = name;
        Url = url;

    public void UpdateVersion()
        // Delegates the plumbing of HTTP requests and markup-parsing to infrastructure.
        var versionChecker = Container.Get<IVersionChecker>();
        var version = versionChecker.GetCurrentVersion(this.Url);

        if (version != this.Version)
            var evt = new WebAppVersionUpdated(
                this.Version /* old version */, 
                version /* new version */);
            this.Version = version;
            this.VersionLatestCheck = DateTime.UtcNow;

            // Now this eems very, very wrong!
            var repository = Container.Get<IWebAppRepository>();
            var updateResult = repository.Update(this);
            if (!updateResult.OK) throw new Exception(updateResult.Errors.ToString());


         * I feel that the aggregate should be responsible for checking and updating its
         * version, but it seems very wrong to access a Global Container and create the
         * necessary instances this way. Dependency injection should occur via the
         * constructor, and making the aggregate depend on infrastructure also seems wrong.
         * But if I move such methods to WebAppService, I'm making the aggregate
         * anaemic; It will become just a simple bag of getters and setters.
         * Please advise.

    public void UpdateIsAlive()
        // Code very similar to UpdateVersion().

And a DomainService class to handle Creates and Deletes, which I believe are not the concern of the Aggregate itself.

public class WebAppService
    private readonly IWebAppRepository _repository;
    private readonly IUnitOfWork _unitOfWork;
    private readonly IEventDispatcher _eventDispatcher;

    public WebAppService(
        IWebAppRepository repository, 
        IUnitOfWork unitOfWork, 
        IEventDispatcher eventDispatcher
    ) {
        _repository = repository;
        _unitOfWork = unitOfWork;
        _eventDispatcher = eventDispatcher;

    public OperationResult RegisterWebApp(NewWebAppDto newWebApp)
        var webApp = new WebApp(newWebApp);

        var addResult = _repository.Add(webApp);
        if (!addResult.OK) return addResult.Errors;

        var commitResult = _unitOfWork.Commit();
        if (!commitResult.OK) return commitResult.Errors;

        _eventDispatcher.Publish(new WebAppRegistered(webApp.Id, webApp.Name, webApp.Url);
        return OperationResult.Success;

    public OperationResult RemoveWebApp(Guid webAppId)
        var removeResult = _repository.Remove(webAppId);
        if (!removeResult) return removeResult.Errors;

        _eventDispatcher.Publish(new WebAppRemoved(webAppId);
        return OperationResult.Success;


The class below provides an interface for the WebMonitoring domain to the outside world (web interfaces, rest api's, etc). It's just a shell at this moment, redirecting calls to the appropriate services, but it would grow in the future to orchestrate more logic (accomplished always via domain models).

public class WebMonitoringAppService
    private readonly IWebAppQueries _webAppQueries;
    private readonly WebAppService _webAppService;

     * I'm not exactly reaching for CQRS here, but I like the idea of having a
     * separate class for handling queries right from the beginning, since it will
     * help me fine-tune them as needed, and always keep a clean separation between
     * crud-like queries (needed for domain business rules) and the ones for serving
     * the outside-world.

    public WebMonitoringAppService(
        IWebAppQueries webAppQueries, 
        WebAppService webAppService
    ) {
        _webAppQueries = webAppQueries;
        _webAppService = webAppService;

    public WebAppDetailsDto GetDetails(Guid webAppId)
        return _webAppQueries.GetDetails(webAppId);

    public List<WebAppDetailsDto> ListWebApps()
        return _webAppQueries.ListWebApps(webAppId);

    public OperationResult RegisterWebApp(NewWebAppDto newWebApp)
        return _webAppService.RegisterWebApp(newWebApp);

    public OperationResult RemoveWebApp(Guid webAppId)
        return _webAppService.RemoveWebApp(newWebApp);

Closing the Matters

After gathering of answers here and in this other question, which I opened for a different reason but ultimatelly got to the same point as this one, I came up with this cleaner and better solution:

Solution proposition in Github Gist

  • I've been reading a lot, but I've found not such practical examples, except for the ones applying CQRS and others orthogonal patterns and practices, but I'm looking for this simple thing right now.
    – Levidad
    Jan 2, 2018 at 15:03
  • 1
    This question might be a better fit for codereview.stackexchange.com Jan 2, 2018 at 15:40
  • 2
    I myself like you with lots of time spent with n-tier apps. I know about DDD only from books, forums, etc, so I'll post only a comment. There are two types of validation: input validation and business rules validation. The input validation goes in the Application layer and Domain validation goes in the Domain Layer. The WebApp looks more like an Entity and not an aggreagate and WebAppService looks more like an application service than a DomainService. Also your aggregate references the Container which is an infrastructural concern. It also looks like an service locator. Jan 2, 2018 at 15:44
  • 1
    Yes, because it doesn't model a relation. The aggregates are modeling the relations between the domain objects. WebApp has only raw data and some behavior and might deal for example with the following invariant: is not ok to update the versions like crazy ie steping to version 3 when the current version is 1. Jan 2, 2018 at 16:37
  • 1
    As long as ValueObject has a method that implements the equality between instances, I think is ok. In your scenario you can create a Version value object. Check semantic versioning, you'll get lots of ideas about how can you model this value object, including invariants and behavior. WebApp shouldn't talk to a repository, actually I believe is safe not to have any reference from your project that contains the domain stuff to anything else related to infrastructure (repositories, unit of work) either directly or indirectly (via interfaces). Jan 2, 2018 at 20:31

1 Answer 1


A long the lines of advice on your WebApp aggregate, I fully agree that pulling in the repository is not the right approach here. In my experience the Aggregate will make the 'decision' whether an action is okay or not based on it's own state. Thus not on state it might pull from other services. If you would need such a check, I'd generally would move that to the service which calls the aggregate (in your example the WebAppService).

Additionally, you might land on the use case that several application want to concurrently call your aggregate. If this would happen, whilst you're doing outbound calls like this which might take a long time, you're thus blocking your aggregate for other usages. This would eventually slow down aggregate-handling, something which I think isn't desirable either.

So although it might seem that your aggregate becomes quite thin if you move that bit of validation, I do think it's better to move it to the WebAppService.

I'd also suggest moving the publishing of the WebAppRegistered event in to your aggregate. The aggregate is the guy being created, so if it's creation process succeeds, it makes sense to let it publish that knowlegde to the world.

Hope this helps you out @Levidad!

  • Hi Steven, thanks for your input. I've opened another question here that ultimatelly got to the same point of this question, and I finally came up with a Cleaner Solution attempt for this problem. Would you please take a look and share your thoughts? I think it goes in the direction of your suggestions above.
    – Levidad
    Jan 3, 2018 at 11:50
  • Sure thing Levidad, I'll have a look!
    – Steven
    Jan 4, 2018 at 8:37
  • 1
    I just checked both replies, from 'Voice of Unreason' and 'Erik Eidt'. Both are along the lines of what I would comment on the question you've got there, so I can't really add value there. And, to answer your question: The way you're WebApp AR is set up in the 'Cleaner Solution' you share is indeed along the lines of what I would view as a good approach for an Aggregate. Hope this helps you out Levidad!
    – Steven
    Jan 4, 2018 at 8:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.