Microsoft .NET Architecting Applications for the Enterprise, Second Edition (2014)

---

The Anemic Domain Model (anti-)pattern

The landmark of a domain model is the behavior associated with objects. And “which behavior exactly” is a common objection that boosters of the Domain Model pattern often hear. The Domain Model pattern is sometimes contrasted to another object model pattern known as Anemic Domain Model (ADM).

Generalities of the pattern

In an anemic domain model, all objects still follow the naming convention of real-world domain entities, relationships between entities exist, and the overall structure of the model closely matches the real domain space. Yet, there’s no behavior in entities, just properties. From here comes the use of the adjective anemic in the pattern’s name.

The inspiring principle of ADM is that you don’t deliberately put any logic in the domain objects. All the required logic, instead, is placed in a set of service components that all together contain the whole domain logic. These services consume the domain model, access the storage, and orchestrate persistence.

Inferring models from the database might cause anemia

The canonical example of an anemic domain model is the set of objects you get when you infer a model from an existing database structure. If you do this with Entity Framework, you get a bunch of classes that map all the tables in the database. Each class is filled with properties that are a close adaptation of table columns. Foreign keys and constraints are also honored, yielding a graph of objects that faithfully represent the underlying relational data model.

Classes that Entity Framework generates are declared partial, meaning they can be extended at the source-code level (for example, not through compile-level inheritance). In other words, using Entity Framework in a database-first model doesn’t prevent you from having a behavior-rich model. What you get by default, though, is just an anemic domain model in which all classes are plain containers of properties with public getters and setters.

Is it a pattern or an a anti-pattern?

There’s a general consensus about ADM: it is more of an anti-pattern than a pattern, and it’s a design rule you’d better not follow. We think there’s a conceptual view of it and a pragmatic view, and choosing either might be fine. Let’s see why it is almost unanimously considered an anti-pattern. The words of Martin Fowler are extremely clear in this regard, and you can read them here: http://www.martinfowler.com/bliki/AnemicDomainModel.html. (Note that the article was written over a decade ago.)

In brief, Fowler says that ADM is “contrary to the basic idea of object-oriented design; which is to combine data and process together. The anemic domain model is really just a procedural style design.” In addition, Fowler warns developers against considering anemic objects to be real objects. Anemic objects are, in the words of Fowler, “little more than bags of getters and setters.”

We couldn’t agree more. Additionally, we agree with Fowler when he says that object-oriented purism is good but we “need more fundamental arguments against this anemia.” Honestly, the arguments that Fowler brings to the table sound both promising and nebulous. He also says that ADM incurs all the costs of a domain model without yielding any of the benefits.

In summary, the key benefits referred to by Fowler can be summarized as listed here:

Analysis leads to objects that closely model the domain space and are tailored to the real needs.

The strong domain perspective of things reduces the risk of misunderstandings between the domain experts and the development team.

Code is likely to become more readable and easily understandable.

The final result has more chances to really be close to expectations.

How concrete are these declared benefits? What if the resulting domain model only looks like the real things but leaves a gap to fill? Benefits of a domain model are there if you catch them. In our (admittedly rather defensive and pragmatic) approach to software design, a good anemic model probably yields better results than a bad domain model. In the end, not surprisingly, it’s up to you and your vision of things. It depends on how you evaluate the skills of the team and whether you consider the team capable of coming up with an effective domain model.

The bottom line is that ADM is an anti-pattern, especially if it is used in complex domains where you face a lot of frequently-changing business rules. In the context of data-driven applications and CRUD systems, an anemic model is more than fine.

Moving the focus from data to tasks

For decades, relational data modeling has been a more than an effective way to model the business layer of software applications. In the .NET space, the turning point came in the early 2000s, when more and more companies that still had their core business logic carved in the rough stone of mainframes took advantage of the Microsoft .NET Framework and Internet breakthroughs to renovate and modernize their systems. In only a few years, this poured an incredible amount of complexity on the shoulders of developers. RAD and relational modeling then—we’d say almost naturally—appeared worn out and their limits were exposed. Figure 7-2 illustrates the evolution of data-modeling techniques over the past decades.

FIGURE 7-2 Trends in application modeling.

The figure is neither exhaustive nor comprehensive: it only aims to show changes in patterns and approaches over the years that have been used to produce faithful models.

The chart measures the faithfulness of the produced models and observed processes. It comes as no surprise that Domain-Driven Design improved faithfulness. The advent of DDD also started moving the focus from data-centric design to task-based design. It was a natural move essentially driven by the need to handle complexity in some way.

The transition to a task-based vision of the world is the ultimate message of the Tell-Don’t-Ask principle, which we find generically mentioned more often than concretely applied. Tasks are the workflows behind each use-case and each interaction between the user and the system. From a design perspective, a single layer that contains whatever might exist between presentation and data is a rather bloated layer. In this regard, isolating the orchestration of tasks into a separate layer leaves the sole domain logic to code. Domain logic fits more than naturally either into domain objects or, if an anemic design is chosen, into separate modules.

Let’s look at an example to give more concrete form to what we have so far generically called the application layer.

Task orchestration in ASP.NET MVC

In an ASP.NET MVC application, any user-interface action ends in a method invoked on a controller class. The controller, then, is the first place where you should consider orchestrating tasks. Abstractly speaking, there’s no difference at all between a controller method and postback handler. In much the same way, every savvy developer avoids having full orchestration logic in a Button1_Click event handler, you should avoid having full orchestration logic in a controller method.

Controller as a coordinator

Responsibility-Driven Design (RDD) is a design methodology introduced a decade ago by Rebecca Wirfs-Brock and Alan McKean in the book Object Design: Roles, Responsibilities, and Collaborations (Addison-Wesley, 2002). The essence of RDD consists of breaking down a system feature into a number of actions the system must perform. Next, each action is mapped to a component (mostly a class) being designed. Executing the action becomes a specific responsibility of the component. The role of the component depends on the responsibilities it assumes. RDD defines a few stereotypes to classify the possible role each component can have. We’re not loyal followers of the RDD approach even though we find its practices useful for mechanically breaking up into digestible pieces nuts that are hard to crack.

We think that one of the RDD stereotypes—the Coordinator—meticulously describes the ideal of role of an ASP.NET MVC controller. The RDD Coordinator stereotype suggests you group all the steps that form the implementation of the action within a single application service. From within the controller method, therefore, you place a single call to the application service and use its output to feed the view-model object. That’s exactly the layout we illustrated Here’s the layout again:

public ActionResult PlaceOrder(OrderInputModel orderInfo)
{
// Input data already mapped thanks to the model binding
// infrastructure of ASP.NET MVC

// Perform the task invoking a application service and
// get a view model back from application layer
var service = new OrderService();
var model = service.PlaceOrder();

// Invoke next view
return View(model);
}

The overall structure of the ASP.NET MVC controller method is quite simple. Solicited by an incoming HTTP request, the action method relays most of the job to another component that coordinates all further steps. The call into the OrderService class in the example is where the boundary between the presentation and application layers is trespassed.

There’s an interesting alternative to the code layout just shown that might come in handy when you don’t much like the idea of having a brand new application layer for any new front end. So imagine you have a consolidated application layer and need to add a new front end. The application layer is mostly the same except for some view-model adaptation. In this case, it might be acceptable to add an extra step to the presentation layer, as shown here:

// Get response from existing application layer
var service = new OrderService();
var model = service.PlaceOrder();

// Adapt to the new view model
var newFrontendModel = someAdapter.NewViewModel(response);

In general, you shouldn’t expect the application layer to be fully reusable—the name says it all. However, any level of reusability you can achieve in a specific scenario is welcome. And the more you can reuse, the best. Instead, what is invariably shared and reusable is the domain logic.

Connecting the application and presentation layers

The junction point between application layer and presentation is the controller. In previous chapter, you saw how to use poor-man’s dependency injection to implement it. To use a full-fledged Inversion of Control (IoC) pattern like Microsoft Unity, in ASP.NET MVC you need to override the controller factory. Here’s a code snippet that shows most of it. In global.asax, at the application startup you register a custom controller factory:

var factory = new UnityControllerFactory();
ControllerBuilder.Current.SetControllerFactory(factory);

The class UnityControllerFactory can be as simple as shown here:

public class UnityControllerFactory : DefaultControllerFactory
{
public static IUnityContainer Container { get; private set; }
public UnityControllerFactory()
{
Container = new UnityContainer(); // Initialize the IoC
Container.LoadConfiguration(); // Configure it reading details from web.config
}
protected override IController GetControllerInstance(RequestContext context, Type type)
{
if (type == null) return null;
return Container.Resolve(type) as IController;
}
}

With this code in place, any controller class can be created without the default parameterless constructor:

public class HomeController
{
private IHomeService _service;
public HomeController(IHomeService service)
{
_service = service;
}
...
}