![java domain driven design java domain driven design](https://pbs.twimg.com/media/C5bXovsWMAA5c_a.jpg)
We found that to do that we needed to segregate make the domain/infrastructure segregation at the package level.
![java domain driven design java domain driven design](https://en.jdon.com/images/m.jpg)
We wanted to make sure that the pure domain logic had no dependency at all on infrastructure classes. We were trying to implement something like clean architecture or hexagonal architecture. Since the infrastructure classes were in the same package and the core domain ones, it was hard to make sure that the dependencies pointed in the right direction. It also helps to understand the domain if you can easily see a list of all the classes involved. That way, when you are on a domain or subdomain you can always find all the classes at hand. We really liked the clarity of having all the classes and files related to one domain under the same folder. │ ├── anotherDomainResponseMarshaller.java │ ├── anotherDomainRequestUnmarshaller.java The previous long-lived application had a package structure like following one: src/main/java In this post I will explain the evolution of this structure. One of the challenges we found in doing so was to find the right package structure to organize our source code.
#JAVA DOMAIN DRIVEN DESIGN CODE#
Even though the domain was big and complex, it was usually reasonably easy to navigate the code and change as long as you knew enough about the Ubiquitous Language and the business.įor the greenfield apps, we wanted to apply our interpretation of DDD from scratch. The long-lived one was fairly well structured around it’s domain. In my time in sky I have worked in at least one big long-lived application (8+ years) and a couple of greenfield applications. I am lucky enough to be working in a team that values DDD.