Peter Ritchie's MVP Blog : AntiPattern

A Upcoming Pandemic of Domain Anaemia

PeterRitchie — Thu, 29 Jan 2009 17:10:00 GMT

There's a well-known anti-pattern called the anaemic domain model[1][2]. This anti-pattern basically says domain entities, chronically, have little or no behaviour (remember, object-oriented design is about attributes and behaviour).

It should be obvious that a domain model that isn't truly object oriented is a domain model with a problem. But, let's look at other reasons why the Anaemic Domain Model is an anti-pattern. Your Domain is the nexus, the essence, of your system.

An anaemic domain model is basically a reporting system. Each "Entity" becomes, essentially, a query. This is fine, reporting systems are necessary and prevalent. But, to shoe-horn a domain model on top of this leads away from good reporting patterns that could add value and increases complexity, needlessly. The designers spend most of their time trying to force entities on the system, without recognizing the basic reporting nature of the system. This usually leads to "reports" that have to pull in multiple domain "entities" to generate the report--rehydringing data into an entity (usually through some sort of ORM) with no value added. i.e. an ORM that will manage the child-parent relationship (and either pre-load or lazy-load aggregates) doesn't provide much value here.

The worst case scenario with an anaemic domain model is that there really is behaviour there; but it's not handled in the domain entities; it's handled in a different layer. This is a problem because this circumvents the whole point of a domain model and layering.

One indication of anaemia is that most of the domain classes simply contain attributes. Anyone familiar with patterns should recognize this as a Data Transfer Object, not a Domain Entity. There's nothing wrong with DTOs, they're very important in almost all systems with any sort of complexity; but they're not Domain Entities. Let's be truthful, there are systems with little or no behaviour in the domain; and that's not a bad thing. Systems like this likely don't need a Domain Model and may not need techniques like Domain Driven Design. The quicker people recognize that, the quicker they can be using a more appropriate architecture and design. In some extreme cases the anaemic-domain-entity-DTOs service other DTOs

Now, where am I going with this? Well, there's been a series of guidance out of Microsoft Patterns and Practice about some application "patterns".

First, let me describe what a pattern is. A pattern is a way of "documenting a solution to a design problem" [3]. First, for it to be a pattern, it needs to detail the problem and it's context, then provide a solution. The latest "patterns" from P&P do not detail the problem or a context. They're simply architectural descriptions.

Now the association between the Anaemic Domain Model and the latest P&P guidance. In 3 of the 5 recently publish "patterns" the following is detail is included: "A Domain Entity pattern is used to define business entities that contain data only." This is the very definition of an Anaemic Domain Model. Plus, in the RIA pattern the following, contradictory, detail is included: "Domain entities are responsible for implementing business rules. Entities from the domain model represent business objects that contain data and implement behavior [sic]. In other words, the business objects are responsible for implementing business operations and interacting with other business objects."

This is disconcerting because historically sample code and guidance from Microsoft is simply reused without thought. This leads to poorly designed and architected applications, and the .NET community as a whole is seen as one that produces poor-quality code and design. Without context about the problems these patterns try to solve, they will be misused—likely forced upon contexts and situations where they don’t fit, simply because “they’re from Microsoft”.

[1] MF Bliki- AnemicDomainModel

[2] Anemic Domain Model - Wikipedia, the free encyclopedia

[3] Design pattern (computer science) - Wikipedia, the free encyclopedia

Technorati Tags: Microsoft Patterns and Practicies,Anti-patterns,Anaemic,Anemic,Domain Model,Microsoft

del.icio.us Tags: Microsoft Patterns and Practicies,Anti-patterns,Anaemic,Anemic,Domain Model

House of Cards Design Anti-pattern

PeterRitchie — Tue, 27 Jan 2009 16:00:00 GMT

I've had this anti-pattern in my head for years. It's an observance of some projects and methodologies that I've witnessed over the years. I believe it's a form of Voodoo Programming, Programming by coincidence, and is often a side effect of Cargo Cult Programming.

Anti-Pattern Name
House of Cards Anti-pattern

Problem
A problem occurs when software is written that works in a specific observed scenario but no one knows why it works in that scenario. Observation of "working" is taken as enough evidence of completeness. It is very often not enough to observe something working in one scenario for the software to be considered "correct".

This is often a result of continual hacks in sole response to correcting bugs without consequence to design or maintainability. Repeated hacks (cards) are are placed on top of other hacks until something has the appearance of "working" then all development on it stops and no one wants to go near the code again for fear of breaking it.

At the very least, House of Cards design is fragile, hard to maintain, un-agile. Worst case it's is of low quality and prone to error and data lose.

This is a general sign of cowboy coding. I means there is no acceptable methodology, and no real management. There's little development direction, and likely no development leadership (at least none with any meaningful experience). Features are generally driven solely by an external source that communicates directly with developers.

Symptoms

When reviewing code or questioned about code, developers respond with comments like "don't touch it, it works", or "we don't want to change it because it works". There's a reluctance to change the code because no one really knows why it works. The code stagnates, new features are slow to be implemented, and there's a general un-assuredness about the code.

The code is generally procedural, although following object-oriented syntax.

Refactored Solution

Establish experienced development leadership. Establish a development methodology that separates the stakeholders from the developers.

Invoke Agile methodologies to manage the requirements of the project and begin Agile redesign of the code employing unit testing, refactoring, patterns, etc. Aggressively refactor the code adding unit tests to test for specific problems as they arise, until the code is robust and reliable. Mandate adherence to SOLID principles: classes adhere to Single Responsibility Principle, Open-Closed Principles, Liskov Substitution Principle, Interface Segregation Principle, and uses the Dependency Inversion Principle

Technorati Tags: design,anti-pattern,software development

Pontificating Virtual Parameterized Constructors in C#

PeterRitchie — Tue, 18 Nov 2008 17:55:00 GMT

Tom Hollander recently posted about a change he required to the Enterprise Library for date/time validation. He had to create a new class (rather than modify the Enterprise Library) that derived from another, defective class. One of his complaints was that in order to effectively implement the base class he had to also write matching constructors that simply called the base class. His suggestion was effectively to add the concept of virtual parameterized constructors to C#. I detail “parameterized constructors” because C# already effectively has virtual default constructors. In the following example the base constructor (Form()) is automatically called by the derivative:

    public class MyForm : Form
    {
        public MyForm()
        {
        }
    }

Virtual parameterized constructors are not new, and from a mere language standpoint this seems reasonable. Pragmatically though, I believe, this is another story. It seems logical to be able to simply inherit the parameterized constructors of the base class; but, there are so many times that this isn't the case or some generally accepted principles that would be contravened by a language addition like this.

Let's first look at the open/closed principle (OCP). The OCP suggests classes should be open for extension but closed for modification. Robert Martin suggests [1] properly designed class hierarchies that obey OCP implement an abstraction; i.e. derive from an abstract class or implement an interface. For example:

public interface IShape
{
    void Draw(Graphics graphics);
}
 
public class Rectangle : IShape
{
    //...
    public void Draw(Graphics graphics)
    {
        ///...
    }
}

Second, let's look at the "prefer composition over inheritance" principle. The effect of a language change like this on a design that prefers composition should be fairly obvious. Here's an example of this principle:

public interface IPolygon {
    void Draw(Graphics graphics);
}
public sealed class Polygon {
    private readonly Point[] points;
    public Polygon(Point[] points) {
        this.points = points;
    }
    public void Draw(Graphics graphics) {
        for(int i = 1; i < points.Length; i++) {
            graphics.DrawLine(Pens.Black, points[i-1], points);
        }
    }
}
 
public class Rectangle : IPolygon {
    private readonly Polygon polygon;
    public Rectangle(Point location, Size size) {
        Point[] points = new Point[5];
        points[4] = points[0] = location;
        points[1] = new Point(location.X + size.Width, location.Y);
        points[2] = new Point(location.X + size.Width, location.Y + size.Height);
        points[3] = new Point(location.X, location.Y + size.Height);
        polygon = new Polygon(points);
    }
    public void Draw(Graphics graphics) {
        polygon.Draw(graphics);
    }
}

Obviously there is no way to use virtual parameterized constructors here.

Clearly, designs that take into account OCP and prefer-composition-over-inheritance would not benefit from a "virtual parameterized constructor" language addition.

Finally, let's look at why a class might have many constructors causing such friction for derivatives. There's many reasons why a class might have many constructors. I believe all are indications of a poorly designed class. My first thought would be that many constructors is a result of a large class and that the large-class-code-smell should be an indication for redesign. A large class could be in an indication of a motherclass; but in either case this is likely a single responsibility principle (SRP) violation and the class is doing much more than it should and be redesigned. If the class isn't large but has many constructors, this was likely done not in response to how the class should/would be used but to cover every possible way of constructing the type. This would then be a YAGNI violation and the number of constructors should simply be pared down.

But, what about when you have to deal with poorly design hierarchies and don't have the ability to modify them? A valid point; but, simply for the lack of friction of writing pass-through constructors I don't think adding to the language to support poorly designed classes is a good for the language or its developers.

While an addition like virtual parameterized constructors seems benign, its limited actual usefulness makes the effort not worth the reward. Plus, it introduces greater abilities to create poorly designed types.

[1] http://www.objectmentor.com/resources/articles/ocp.pdf