Showing posts with label DDD. Show all posts
Showing posts with label DDD. Show all posts

Thursday, 15 June 2017

This week 11/2017

After years of programming I have seen good presentations of Kamil Szymański and Jakub Nabrdalik, who in a easy way explained what is a clean code and how to implement DDD in your code. I always was listening to Sławek Sobótka but I  had never known how to write such code until I took a part in Jakub Nabrdalik presentation about class's scopes and hexagonal architecture. Jakub was pointing popular mistakes made by all kind of Java developers as:

- splitting code between packages which describe layers, not functionality

- publication all code of module instead of publish only classes which we want allow to be used by other modules,

- creating a lot of test and affection to them what made production code not refactorable,

- focusing on algorithm testing instead of testing module as black box using behavioural or acceptation tests.

Easy example shows that we should put all services and repositories to one package with package scope and don't publish them to the world. Only fasad interface and dto can be published. This way we care only about contract between fasad and its client. This is the place to focuses on test which check all module and its behaviours. Jakub thinks that unit tests which test internal classes of module could be always deleted if there is difficult to correct them after module's code refactoring.

However Kamil noticed that unit tests​ should test units, not classes, that's why we should care of test code quality the same as about production code.


Resources:

Saturday, 19 November 2016

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