This morning I was reading an article about properties vs attributes by Eric Lippert, one of the designers of the C# language. In it, he explained:
Properties and fields and interfaces and classes and whatnot are part of the model; each one of those things should represent something in the model world. If a property of a “rule” is its “description” then there should be something in the model that you’re implementing which represents this. We have invented properties specifically to model the “an x has the property y” relationship, so use them.
That’s not at all what attributes are for. Think about a typical usage of attributes:
[Obsolete][Serializable]public class Giraffe : Animal{ ...Attributes typically do not have anything to do with the semantics of the thing being modeled. Attributes are facts about the mechanisms – the classes and fields and formal parameters and whatnot. Clearly this does not mean “a giraffe has an obsolete and a serializable.” This also does not mean that giraffes are obsolete or serializable. That doesn’t make any sense. This says that the class named Giraffe is obsolete and the class named Giraffe is serializable.
Now he doesn’t explicitly mention domain-driven design, but I think it’s an important point for .NET developers who’re trying to get into it: attributes are only for implementation details – don’t use them for domain model concepts.