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

Question

What is Cross-Cutting and what is its relation to Aspect Oriented Programming (AOP)? And in a DDD architecture what is its function?

Answer 1

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

In general the components that fulfill a certain responsibility belong only to a single layer and/or occupy a single position in the class hierarchy. However, there are certain aspects that concern more than one layer and cannot be isolated in a specific component without direct relation to all the others. It is said that this aspect "crosses" or "cuts" the hierarchy, or in English that is cross-Cutting ("transverse").

Often the aspects considered cross-Cutting (wikipedia has a list with some of them) are treated in a manner ad-hoc, 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");
}

Aspect-Oriented Programming, on the other hand, seeks centralize each aspect, organize the code that deals with it in a separate set, and then inject this code throughout the project, regardless of the original layer and/or class hierarchy. That way the original code stays clean and focused on your responsibility.

(Note: the example below, in Aspectj, is quite simplified, and I do not know if it reflects current practices. I studied AOP many years ago - even before Java supported Annotations - and I haven’t brought it up since.)

In the main class:

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

In the "aspect":

@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;
    }
  }
}

^Source

Here we have an example of dependency injection - the original code is not "aware" that no record is being made, it simply fulfills its function and that’s it! The aspect itself - when enabled (and as I recall it is possible to enable/disable aspects at least at compile time or load) - is who injects his code in the specific points necessary to fulfill his function. The dependency relationship between the layers remains simple and is respected by its members, only the aspect cross-Cutting need to make reference to all others (not necessarily in a strongly coupled way as in this example).

By the way, AOP is not strictly necessary to treat well aspects cross-Cutting - some languages, such as Python, make extensive use of decorators to isolate aspects outside the responsibility of the layer. 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 the problem is by using mixins (i.e. "inherited" code by classes of different hierarchies, without necessarily having any relation to each other).

Finally, the definition of cross-Cutting This is it, but to know if an aspect is cross-Cutting or it won’t depend on what your architecture is. If your hierarchy is one way, certain aspect can be easier to "fit" if it is another, no. Anyway, there will always be cases where a certain functionality "crosses" several layers and/or affects classes of different hierarchies, and these cases will require some form of treatment, whether "disorganized" (spreading related code [among themselves] throughout the system), or "organized", through one of the techniques described above or another similar.

Answer 2

And in a DDD architecture what 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 the Infrastructure Layer is:

Provide generic technical features that support the higher layers: messaging to the application, persistence to the domain, design of widgets for the user interface, etc. The infrastructure layer can also 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 you owning your Data project with your repositories, you will also have a Cross-Cutting project within your Layer responsible for:

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

For example Inversion Of Control.

Your application, your repository, your own infrastructure, and your services, use or may 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 its relationship to 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 as the DDD, in the 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 architecture as an example the Ioc itself (Inversion Of Control), thus being a strong candidate to be part of the Cross-Cutting project