What is Cross-Cutting and what is its relationship to Aspect Oriented Programming (AOP)?

Many aspects of a system are designed hierarchical and / or layers . This assumes that not every component of the system needs to interact with any other component, and the organization of the components is done in cohesive groups with the function of fulfilling a very specific responsibility.

Ingeneral,componentsthatfulfillacertainresponsibilitybelongonlytoasinglelayerand/oroccupyasinglepositionintheclasshierarchy.However,therearecertainaspectsthatconcernmorethanonelayer,andcannotbeisolatedinaspecificcomponentwithoutdirectrelationwithalltheothers.Itisthensaidthatthisaspect"crosses" or "cuts" the hierarchy, or in English that is cross-cutting .

Manytimescross-cuttingaspects(Wikipediahas a list with some of them) are handled in an ad-hoc manner, for example spreading throughout the code calls unrelated to the primary function of the same:

void calcularImposto() {
    log("Iniciando o cálculo");
    if ( numeroPeriodos == 0 ) {
        log("Número de períodos igual a zero", Logging.ERROR);
        throw new StateException("Número de períodos igual a zero");
    }
    ...
    log("Cálculo efetuado com sucesso");
}

(Note: The example below, in AspectJ, is fairly simplified, and I do not know if it reflects current practice.) I studied AOP for many years - before Java even supported annotations - and not I've touched on the subject ever since.)

In the main class:

void calcularImposto() {
    if ( numeroPeriodos == 0 )
        throw new StateException("Número de períodos igual a zero");
    ...
}

No "look":

@Aspect
public class MethodLogger {
  @Around("execution(* calcular*(..))")
  public Object around(ProceedingJoinPoint point) {
    log("Iniciando o cálculo");
    try {
        Object result = point.proceed();
        log("Cálculo efetuado com sucesso");
        return result;
    } catch(StateException e) {
        log("Número de períodos igual a zero", Logging.ERROR);
        throw e;
    }
  }
}

Font

Here is an example of dependency injection - the original code does not "know" that no record is being made, it simply fulfills its function and that's it! The aspect itself - when enabled (and from what I remember it is possible to enable / disable aspects at least at compile time or load) is who injects their code into the specific points needed to fulfill their function. The dependency relation between the layers remains simple and is respected by its members, only the cross-cutting aspect needs to reference all the others (not necessarily strongly coupled as in this example).

By the way, AOP is not strictly necessary to handle well cross-cutting aspects - some languages, such as Python, make extensive use of decorators to isolate aspects not belonging to the layer's responsibility. The main difference is that this needs to be done explicitly, there is no inversion of control:

def logado(fn):
    def ret(*args, **kwargs):
        log("Iniciando o cálculo")
        try:
            resultado = fn(*args, **kwargs)
            log("Cálculo efetuado com sucesso")
            return resultado
        except:
            log("Número de períodos igual a zero", Logging.ERROR)
            raise
    return ret

@logado
def calcular_imposto():
    ...

Another way to deal with this problem is to use mixins ( ie code "inherited" by classes of different hierarchies, without necessarily having any relation to each other).

Anyway, the definition of cross-cutting is this, but to know if an aspect is cross-cutting or not it will depend on what your architecture is. If your hierarchy is in one way, one aspect may be easier to "fit in", if it is in another, no. In any case, there will always be instances where a particular feature "crosses" several layers and / or affects classes of different hierarchies, and these cases will require some form of treatment, be "disorganized" (spreading related code [ among them] throughout the system), or "organized", through one of the techniques described above or another similar.

  

And in a DDD architecture what is its function?

In a DDD architecture, Eric Evans in his 2004 book entitled: Tackling Complexity in the Heart of Software tells us that the function of Infrastructure Layer is:

  

Provide generic technical features that support the higher layers:   sending message to the application, persistence to the domain,   drawing widgets for the user interface, etc. The infrastructure layer can also   to support the pattern of interactions between the four layers through a   architectural structure.

And that's exactly where Cross-Cutting comes into play:

For example, in addition to having your Data project with your repositories, you will also have a Cross-Cutting project inside your infrastructure layer responsible for:

  

Support the pattern of interactions between the four layers through a   architectural structure.

As for example Inversion Of Control.

Your application, your repository, your own infrastructure, and your services, use or can use an IoC framework, and this is the responsibility of Infratructure, Cross-Cutting.

There are other examples too, such as system logging, another cross-cutting responsibility in the DDD architecture.

  

What is your relationship with Aspect Oriented Programming (AOP)?

Simple, cross-cutting is a concept that can be used in any architecture, in the case of AOP, it follows practically the same philosophy of DDD, in AOP, you separate the responsibilities according to the aspects, and one of the aspects is exactly the part of the "code" where you identify that will be used throughout the architecture as an example of the IoC (Inversion Of Control), thus being a strong candidate to be part of the Cross-Cutting project