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.