Peter Ritchie's MVP Blog : OOD

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

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

Excellent Overview of Domain-Driven Design and Why it Helps

PeterRitchie — Thu, 17 Jul 2008 13:28:00 GMT

Deep-fried Bytes has a podcast with David Laribee where they chat about Domain-Driven Design (DDD), some of it's fundamental principles and patterns. It's part one of two; but, It's an excellent overview of DDD and why it helps.

Fundamentals of OOD Part 3: Method Cohesion

PeterRitchie — Tue, 10 Jun 2008 19:26:00 GMT

Single Responsibility Principle (SRP) helps us write more cohesive types and methods. Cohesion is the relatedness of the members of a type to each other and the relatedness parts of a method's code to other parts.

Method cohesion
Often times a method is not very cohesive, meaning the code that it executes relates to more than one thing. This can often be seen with a method that contains a large switch statement. For any invocation of the method only one case statement may be executed; meaning that blocks of code within the method don't relate to all the other blocks. Switch statements are often an indication that the design should be changed to be more polymorphic or introduce a pattern like the Strategy or Template Method patterns. Likely a concept of the design is implicit instead of explicit (at least no more explicit than an enum). For example:

    public class Set {
        public enum Operation {
            Unknown,
            Union,
            Intersection,
            RelativeComplement,
            And,
            Conjunction = And
        }
 
        public static IList<int> PerformOperation(IList<int> one, IList<int> two, Operation operation) {
            List<int> result = new List<int>();
            switch (operation) {
                case Operation.Union:
                    result.AddRange(one);
                    result.AddRange(two);
                    break;
                case Operation.Intersection:
                    foreach (int x in one) {
                        if (two.Contains(x)) {
                            result.Add(x);
                        }
                    }
                    break;
                case Operation.RelativeComplement:
                    foreach (int x in one) {
                        if (!two.Contains(x)) {
                            result.Add(x);
                        }
                    }
                    break;
                case Operation.And:
                    foreach (int x in one) {
                        if (two.Contains(x)) {
                            result.Add(x);
                        }
                    }
                    break;
                default:
                    throw new ArgumentOutOfRangeException("operation");
            }
            return result;
        }
    }

This code works; but it's far from cohesive. There are many combinations of execution paths this method can take, and each path is unrelated to the other paths. For example, the Union case has no relation to any of the other cases. Methods like this are also hard to maintain and prone to errors. Obviously if another member were added to Operation PerformOperation would have to change--making PerformOperation tightly coupled to Operation--not very object oriented.

This can be made more object-oriented by through Dependency Inversion and the Strategy Pattern:

    public class Set2 {
        public abstract class Operation {
            public abstract IList<int> Execute(IList<int> left, IList<int> right);
        }
 
        public class UnionOperation : Operation {
            public override IList<int> Execute(IList<int> left, IList<int> right) {
                List<int> result = new List<int>();
                result.AddRange(left);
                result.AddRange(right);
                return result;
            }
        }
 
        public class IntersectionOperation : Operation {
            public override IList<int> Execute(IList<int> left, IList<int> right) {
                List<int> result = new List<int>();
                foreach (int x in left) {
                    if (right.Contains(x)) {
                        result.Add(x);
                    }
                }
                return result;
            }
        }
 
        public class RelativeComplementOperation : Operation {
            public override IList<int> Execute(IList<int> left, IList<int> right) {
                List<int> result = new List<int>();
                foreach (int x in left) {
                    if (!right.Contains(x)) {
                        result.Add(x);
                    }
                }
                return result;
            }
        }
 
        public class AndOperation : Operation {
            public override IList<int> Execute(IList<int> left, IList<int> right) {
                List<int> result = new List<int>();
                foreach (int x in left) {
                    if (right.Contains(x)) {
                        result.Add(x);
                    }
                }
                return result;
            }
        }
        public static IList<int> PerformOperation(IList<int> left, IList<int> right, Operation operation) {
            return operation.Execute(left, right);
        }
    }

Now each operation is encapsulated, explicit, PerformOperation need not change as new strategies are added, and we've completely avoided the InvalidOperationException.