Implementing Bounded Context with Entity Framework in a 3-Layer Architecture

Question

I have watched Julie Lerman's videos about using EF in an enterprise application. Now I am developing a website using "Bounded Contexts" and other stuff she has taught in that series.

The problem is I do not know how to use bounded contexts (BC) from within my "Business Layer". To make it clearer: How should the BL know that which specific BC it should use.

Suppose the UI requests a list of products from the business layer. In BL I have a method that returns a list of products: GetAll(). This method does not know which part of the UI (site admin, moderator or public user) has requested the list of products. Since each user/scenario has its own bounded context, the list needs to be pulled using that related context. How should the BL choose the appropriate BC?

Moreover I do not want the UI layer to interact with data layer.

How can this be done?

Answer 1

If by business layer you mean a place where all your business rules are defined, then that is a bounded context.

A bounded context looks at your system from a certain angle so that business rules can be implemented in a compartmentalised fashion (with the goal that it is easier to handle the overall problem by splitting in to smaller chunks).

http://martinfowler.com/bliki/BoundedContext.html

Front-end

So assuming you have a ASP MVC front end, this controllers are the things that will call your use cases/user stories that are presented from the domain to be called via a standard known interface.

public class UserController : Controller
{
    ICommandHandler<ChangeNameCommand> handler;

    public UserController(ICommandHandler<ChangeNameCommand> handler)
    {
        this.handler = handler;
    }

    public ActionResult ChangeUserName(string id, string name)
    {
        try
        {
            var command = new ChangeNameCommand(id,name);
            var data = handler.handle(command);
        }
        catch(Exception e)
        {
            // add error logging and display info
            ViewBag.Error = e.Message;
        }

        // everything went OK, let the user know
        return View("Index");
    }
}

Domain Application (Use Cases)

Next, you would have an domain application entry point that implements the use case (this would be a command or query handler).

You may call this directly and have the code run in-process with your front end application, or you may have a WebAPI or WCF service in front of it presenting the domain application services. It doesn't really matter, how you the system is distrusted depends on the system requirements (it is often simpler from an infrastructure perspective to not to distribute if not needed).

The domain application layer then orchestrates the user story - it will new up repositories, fetch entities, perform an operation on them, and then write back to the repository. The code here should not be complex or contain logic.

public class NewUserHandler : ICommandHandler<ChangeNameCommand>
{
    private readonly IRepository repository;

    public NewUserHandler(IRepository repository)
    {
        this.repository = repository;
    }

    public void Handle(ChangeUserName command)
    {
        var userId = new UserId(command.UserId);
        var user = this.repository.GetById<User>(userId);
        user.ChangeName(command.NewName);
        this.repository.Save(newUser);
    }
}

Domain Model

The entities them selves implement their own business logic in the domain model. You may also have domain services for logic which doesn't naturally fit nicely inside an individual entity.

public class User
{
    protected string Name;
    protected DateTime NameLastChangedOn;

    public ChangeName(string newName)
    {
        // not the best of business rules, just an example...
        if((DateTime.UtcNow - NameLastChangedOn).Days < 30)
        {
            throw new DomainException("Cannot change name more than once every 30 days");
        }

        this.Name = newName;
        this.NameLastChangedOn = DateTime.UtcNow;
    }
}

Infrastructure

You would have infrastructure which implements the code to fetch and retrieve entities from your backing store. For you this is Entity Framework and the DbContext (my example code above is not using EF but you can substitute).

Answer to your question - Which bounded context should the front end application call?

Not to make the answer complex or long, but I included the above code to set the background and hope to make it easier to understand as I think the terms you are using are getting a little mixed up.

With the above code as you started implementing more command and query handlers, which bounded context is called from your front end application depends on what specific user story the user wishes to perform.

User stories will generally be clustered across different bounded contexts, so you would just select the command or query for the bounded context that implements the required functionality - don't worry about making it anything more complicated than that.

Let the problem you are trying to solve dictate the mapping, and dont be afraid that this mapping will possibly change as insight in to the problem you are looking to solve improves.

Sidenote

As a side note to mention things I found useful (I started my DDD journey with EF)... with entity framework there are ORM concepts that are often required such as defining mapping relationships and navigation properties between entities, and what happens with cascade deletes and updates. For me, this started to influence how I designed my entities, rather than the problem dictating how the entities should be designed. You may find this interesting: http://mehdi.me/ambient-dbcontext-in-ef6/

You may also want to look at http://geteventstore.com and event sourcing which takes away any headaches of ORM mapping (but comes with added complexity and workarounds needed to get acceptable performance). What is best to use depends on the situation, but its always good to know all the options.

I also use SimpleInjector to wire up my classes and inject in to the MVC controller (as a prebuilt Command or Query handler), more info here: https://cuttingedge.it/blogs/steven/pivot/entry.php?id=91.

Using an IoC container is a personal preference only and not set in stone.

This book is also awesome: https://vaughnvernon.co/?page_id=168

I mention the above as I started my DDD journey with EF and the exact same question you had.