anchor.diff:  ----
   
   Alternatively, you can use xref:refguide:applib:index/services/inject/ServiceInjector.adoc[ServiceInjector] to inject domain services after the mixin has been instantiated.
  -You'll need to use this method if using nested non-static mixins:
  +You'll need to use this method if using nested non-`static` mixins:
   
   
   [source,java]
  
positive.code:     // ...
  }
  ----
  <.> Domain event is genericised on the mixin, not on the mixee
  <.> Not static.
  Can be camelCase or PascalCase, either will work.
  <.> Acts on the owning instance.
  <.> xref:business-rules.adoc[Supporting methods] follow the same naming convention.
  <.> Acts on the owning instance.
  
negative.code: 
  Accordingly, a mixin can be defined using the xref:refguide:applib:index/annotation/Action.adoc[@Action], xref:refguide:applib:index/annotation/Property.adoc[@Property] or xref:refguide:applib:index/annotation/Collection.adoc[@Collection] annotations, but defined at the domain class level rather than at the method level.
  
  The mixin is expected to follow the naming convention `SomeType_mixinName`, with the name of the contributed member being contributed is inferred from the name of the class itself, being everything after the last '_'.
  For example, if the mixin is called `DocumentHolder_documents`, then the mixee is `DocumentHolder` interface, and `documents` is the name of the contributed collection.
  
  This example also hints at why mixins are so powerful: the mixee's type is usually an interface, not a concrete class.
  Thus, any class that implements `DocumentHolder`, eg `Customer` or `Order`, will be contributed to.
  
  == Contributed Collection
  
  The example below shows in more detail how to contribute a collection, using xref:refguide:applib:index/annotation/Collection.adoc[@Collection].
  The method is expected to be called "coll":
  
  [source,java]
  