In a recent post about writing Active Conventions with NDepend, Jan Van Ryswyck exposes some great CQL conventions:

Being the huge DDD adept that I am, I want to enforce that the domain is the core, the centerpiece, the kernel as you may of my application. I don’t want it to have any dependencies to other assemblies in my application, especially not the infrastructure assembly.

// <Name>Domain is directly using the infrastructure</Name>
WARN IF Count > 0 IN SELECT METHODS FROM ASSEMBLIES "MyProject.Domain"
WHERE IsDirectlyUsing "ASSEMBLY:MyProject.Infrastructure"

It can’t get any easier than this, now doesn’t it? This is actively enforcing Separation of Concerns. Another way to have a convention about this is the following:

// <Name>Domain-Driven Design convention</Name>
WARN IF Count > 0 IN SELECT ASSEMBLIES WHERE 
AssemblyLevel > 1 AND NameIs "MyProject.Domain"

This means that my domain assembly can only have a reference to the .NET framework assemblies and nothing else. This gets my geek heart pounding. Imagine the possibilities if you incorporate this with your daily and
continuous integration builds. Pure software quality assurance if you ask me.

Here are some other conventions in the same spirit:

// <Name>Domain-Driven Design convention</Name>
WARN IF Count > 0 IN SELECT ASSEMBLIES WHERE 
IsDirectlyUsedBy "ASSEMBLY:MyProject.Domain" AND !IsFrameworkAssembly
// Framework or Tier assemblies are those your app is using, 
// such as .NET Fx assemblies.

// <Name>Domain-Driven Design convention</Name>
WARN IF Count > 0 IN SELECT NAMESPACES WHERE 
IsDirectlyUsedBy "ASSEMBLY:MyProject.Domain" AND !NameIs "System"
// Domain code can only used System’s types such as
// string, int, bool…

Personnally I like the following convention that makes sure that domain objects are only made of primitive types, what we could call PONO : Plain Old .NET Object in reference to Java POJO or POCO, Plain Old CLR Object. Such convention garantees that domain object are re-usable accross layers and potentially increase performance since all these primitive types are CLR-optimized. This also helps enforce the currently fashionable concept of persitance ignorance.

// <Name>Domain-Driven Design convention: PONO</Name>
WARN IF Count > 0 IN SELECT TYPES WHERE 
IsDirectlyUsedBy "ASSEMBLY:MyProject.Domain" AND 
!( FullNameIs "System.String" OR FullNameIs "System.Boolean" OR
   FullNameIs "System.SByte" OR FullNameIs "System.Byte" OR
   FullNameIs "System.Int16" OR FullNameIs "System.UInt16" OR
   FullNameIs "System.Int32" OR FullNameIs "System.UInt32" OR
   FullNameIs "System.Int64" OR FullNameIs "System.UInt64" OR
   FullNameIs "System.Char" OR FullNameIs "System.Decimal" OR
   FullNameIs "System.Double" OR FullNameIs "System.Single")
// Make sure that my Domain objects are PONO:
// Plain Old .NET Object.

The PONO convention could be refined with collection types, diagnostic types such as System.Diagnostics.Debug, some special attributes such as System.ParamArrayAttribute and eventually some serialization infrastructure types System.SerializableAttribute (but then, take care of what you mean by persistance ignorance ?!).

Notice that all these is easy to adap if your Domain objects are embedded in a namespace instead of an assembly.