Peter Ritchie's MVP Blog : Microsoft

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

Received Microsoft MVP Award in C# Again

PeterRitchie — Wed, 02 Jul 2008 17:49:00 GMT

It appears my involvement in the technical communities over the past year have caused me to be re-awarded Microsoft MVP C# for a third year.

Entity Framework Petition of Vote of Non Confidence

PeterRitchie — Wed, 25 Jun 2008 17:21:00 GMT

I had intended to be happy simply being a signatory of ADO .NET Entity Framework Vote of No Confidence. But, there's people suggesting signatories of this petition are wackos or on the fringe.

Do yourself a favour and read the petition. Read what we have issues with and how we think Entity Framework (EF) can be improved to be a better product. Read seminal material by industry leaders on entity-oriented and object-oriented application development like Domain Driven Design, and Agile Principles, Patterns and Practices in C# (and the predecessor Agile Software Development: Principles, Patterns and Practices) and Applying Domain-Driven Design and Patterns: With Examples in C# and .NET. If after you have understand this information, you think being forced to use EF on a software development team would mean it would be hard to implement generally accepted object-oriented and entity-oriented design, the sign the petition.

Yes, you have the choice no to use EF; but you also have the choice to help people to not have to deal with the issues detailed in the petition simply because they were not made aware of them.

And despite the naysayers of people who think EF should improve, the ADO.NET team is listening and agrees.

Spaces or Tabs?

PeterRitchie — Mon, 26 May 2008 14:25:00 GMT

In this day and age it seems silly to get into a discussion about whether your companies coding guidelines should have a section mandating either spaces or tabs for indents. Tabs are clearly more flexible, but I really don't think it matters at all; people can easily read code that contains spaces or tabs.

But, Microsoft has departed from what seems to be the rest of the world and is mandating spaces in their new Microsoft Source Analysis Tool for C#.

Word is that an update will not only mandate spaces but mandate 4 for indents.

Again, I don't think it's much of an issue; except Microsoft Source Analysis Tool for C# doesn't offer a rule to mandate tabs over spaces. They're not providing a tool for organizations to use to enforce local coding guidines, but providing a tool to mandate Microsoft's coding guidelines.

The tool can be downloaded here and a discussion on tabs can be found here.

System.Collections classes are obsolete

PeterRitchie — Tue, 26 Jun 2007 16:36:00 GMT

Collection classes like ArrayList, SortedList, Stack and Hashtable will shortly be obsoleted (i.e. the ObsoleteAttribute will be applied to them in upcoming .NET Framework builds). You can start to see this in the Silverlight Alpha (i.e. the Obsolete attribute), but they will be physically unavailable in the release version.

More details can be found in a recent Base Class Library Team blog entry Non-Generic Collections to be Removed from Silverlight.

Even if you don't plan on writing Silverlight-compatible code you should avoid using the types detailed in the BCL Teams blog because they'll be obsolete in other future versions of the .NET Framework.

DateTime.ToUniversalTime Should Throw Exceptinos.

PeterRitchie — Tue, 12 Jun 2007 17:25:00 GMT

A recent .NET Base Class Library blog post points out that DateTime.ToUniversalTime does not throw an exception for overflow values.

This circumvents different Microsoft-sanctioned guidelines about using exceptions for exceptional situations, error reporting guidelines, not using return codes to communicate errors (which essentially what this is), the Method/TryMethod pattern, allowing the error to propagate to a level that knows how to deal with it, etc.

I would recommend having overflows handled as exceptions and the addition of a TryToUniversalTime. If the Method/TryMethod pattern is the favoured approach to providing two methods that result in the same thing--one without exceptions--this is impossible if the Method doesn't throw exceptions. i.e. you can't use Method/TryMethod pattern and therefore if you provided another method to convert to universal time that did throw exceptions, you'd be forced to implement a completely different pattern.

The argument will be that ToUniversalTime can't change because there's code that assumes it doesn't throw an exception. I would argue that this isn't a realistic case and that code that uses ToUniversalTime simply does no error checking because it can't: MinValue and MaxValue are valid values you can't use them to decide whether an error has occurred.

The argument to not change a defective method because something may depend on that defect is just wrong and is used too much as a crutch to avoid not having to deal with redesigning a proper method and dealing with the consequences.

This would apply equally to TimeZone.ToUniversalTime.

Microsoft Open Source Lab

PeterRitchie — Fri, 16 Mar 2007 05:19:00 GMT

After the the Microsoft MVP Global Summit, I got a chance to meet with Sara Ford where she gave me a wonderful tour of campus. Part of that tour was an introduction to some of the folks at port25.com and a look at the open source lab. The port 25 folks are busy building an impressive set of servers (blades, HPC, etc) running various OSes (like many distributions of Linux and Unix, Windows Server, Compute Cluster Server, etc.) performing various tasks like interoperability tests and codeplex.com tasks.

I can't do the complexity of their installation justice--a more detailed description can be found at http://port25.technet.com/archive/2006/03/31/A-Look-Inside-Microsoft_2700_s-Open-Source-Software-Lab-_2800_Part-1_2900_.aspx