This week 19/2016

This article is a summary of thoughts about implementing a piece of DDD in my application. This weekend I disinterred an old topic: How can I design something similar to the DDD in my application and don't turn over all existing application? How can I gently get into.
In inherited application there is strongly used hibernate. Entities model looks like it tries to build a full domain model - they have states and behaviours. However all functionalities use entities in view (and Session on view pattern) and it is difficult to do hermetic model especially then all entity attributes has public setters and getters.

My idea were:

• to retrieves entities only to service level and then map them to immutable dto and dto use in views or if it was necessary map them to mutable Java Plain Object.
• change access type for data in entitles. Till now there was property access an there was impossible to remove setter method from entity. I prefer field access. It is much more transparent and allow to remove getters and setters which can be implemented by Lombok library.
• add new layer - application layer which collect a few independent functionalities and share them to controller.
• I changed packaging of my classes. Classes were included to packages split in order: layer name, functionality. Now I package my classes in order: functionality, layer, but I still thinking about removing layer part of packages and much more granulate functionality.
• reports contains data from many independent tables. I get data by native sql directly mapped to immutable dto.

Now I was focused on bounded domain model and how to resolve it in my application. In this application I should much more use CQRS pattern.


Anyway I think about some other implementation problems, ex. how should I implement JPA entities of bounded context? One context needs only a few attributes of all model, other needs some other but that attributes are archived in one db table.

I still looking for best solutions:)

Bellow I added a few interesting resources:

ddd series

ddd-in-practice

dddexample

domain-driven-design-with-java-ee-6

ddd-and-spring

This week 18/2016

When I was at Devoxx 2016 conference, I chose one of DuyHai DOAN's presentation. I was late and I went at 15 minutes. It seemed that he was talking about some DSL framework so I was disappointed and bored. Lucky I tried to watch the presentation one more time and now I know that I didn't understand the context, the first 10 minutes was the most interesting.

However, to the point. Inspirited by DuyHai DOAN's presentation, I have interested in Annotation Processing. I found a good and clear article about this subject and all became easy.

But to the point. what is the Annotation Processing?

It is a phase of Java code compilation to byte code by javac. As you can see at picture bellow

http://openjdk.java.net/groups/compiler/doc/compilation-overview/javac-flow.png

at the beginning of compilation, the code is parsed and there is created a syntax's dictionary. Then there is executed the Annotation Processor which can read Java code or create new one. (There is assumption, the Annotation Processor can't modify existing code but there is some possibility. I will write about it later).

If the Annotation Processor creates new code, all cycle is repeated. If not, all code is analysed and translated to byte code. 

To study the Annotation Processor, I created 3 projects:

• my annotation 
• my implementation of the Annotation Processor 
• some code in which I used my annotation.

Annotation: 

Notice a Retention Policy type.

@Retention(RetentionPolicy.SOURCE)
@Target({ ElementType.TYPE })
public @interface Getter {
}

Annotation Processor:

I created a file "javax.annotation.processing.Processor" in path "META-INF/services" and I put into it a path to implementation of my Annotation Processor 

@SupportedAnnotationTypes("test.annotationprocessor.annotation.Getter")
@SupportedSourceVersion(SourceVersion.RELEASE_6)
public class GetterProcessor extends AbstractProcessor {

    public GetterProcessor() {
        super();
    }

    @Override
    public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {
        createClassWithVelocityTemplate(roundEnv);
        return true;
    }

    public void createClassWithVelocityTemplate(RoundEnvironment roundEnv) {
        Set<? extends Element> elements = roundEnv.getElementsAnnotatedWith(Getter.class);
        for (Element element : elements) {
            try {
                FileObject in_file = processingEnv.getFiler().getResource(StandardLocation.SOURCE_PATH, "", element.asType().toString().replace(".", "/") + ".java");

                CharSequence data = in_file.getCharContent(false);
                String data1 = addAFewMethods(data).toString();

                FileObject out_file = processingEnv.getFiler().createResource(StandardLocation.SOURCE_OUTPUT, "", element.asType().toString().replace(".", "/") + ".java");
                Writer w = out_file.openWriter();
                w.append(data1);

                velocityGeneration(w);
                w.close();

            } catch (IOException e) {
                e.printStackTrace();
            }
        }

....

    }

}

It reads a source of class with my annotation and create new class with additional code.


To be drawing subject to the end, it is good to mention in a nutshell: 

1. Annotation Processing is supported by IDEs like Eclipse or IntelliJ. It is required to check this option in project settings.
2. As I mentioned above, the Annotation Processor can read and create new code, however authors of Lombok library have found a bypass to this limit. Their library works as it could change a code. They modifies a syntax's dictionary and inject their code. 
3. Javac doesn't use JVM but it is possible to debugging code in your IDE. When a debug option is added to execute command, javac shares an interface like JVM for remote connections.