Upon seeing the title, seasoned application developers or software architects who has used Domain Driven Design in their work would probably go like, “who is this idiot?”
But please hear me out: my intention is to help people with similar experience as I did.
Domain Driven Design (DDD) as a development methodology was born out of the desire to solve the complexity of building software for organisations with evolving business needs. It put focus on the core domain and the domain logic. Whether DDD is successfully applied is highly dependent on developing the Ubiquitious Language which will be used throughout the whole project, ranging from the documentations to the actual code itself. Discipline when it comes to implementation details such as enforcing proper encapsulation and applying true object-orientation by the project team is also needed. DDD as a term was coined by Eric Evans who titled his book with the same name. That book is also known as the blue book.
Complex business software are generally web-based or cloud-based because of scalability, deployment, and volume reasons. Experts who have been in this long enough, do correct me if I’m wrong. Thick clients, which have their business logic and rules implemented in the same package or executable, typically ran on the same machine as where the user do his or her work. In most cases, these applications are not that complex. They tend to only run on a few users’ computers, and sometimes for the sake of synchronization or having common data, there will be one database running on-premise in some server room within the company. However, non-cloud based word processors, spreadsheets, etc are totally different beasts. I think companies like Microsoft, Apple can attest to that since they do built productivity suites for the desktop/laptops.
In the age of cloud-based solution, web-based stack don’t need any introduction. But when it comes to thick-clients, for those who didn’t know, there are also quite a few frameworks that developers can use. If you are using Java, you will probably use Java Swing and/or Java FX, which is newer and better in so many sense. Otherwise there is the Windows Form from .NET Framework. There are also other framework like QT for C++, and wxPython for Python. There are many more but I’m not going to mention them here as it is not the point of this entry. As per the title, I will be focusing on Java Swing only.
I started as a Internal Product Developer, as part of my Diploma internship. In the name of speed, I focused on delivering solutions in the form of thick clients. Web applications need a lot more work on the User Interface side and I’m just no good at that at the start. Furthermore, given that the company I was with had only a few users. So thick client applications seemed to be the best choice then.
Now you must be wondering where I get to work on Java Swing. Concurrently, I had a second job. It was a freelance job with another company. I worked for that company during my internship, and went back to them after I finished my National Service. It continued all the way through my Degree program. In fact, I’m still doing freelance for them until today. It’s been nearly 7 years, excluding my internship time. Throughout the years I worked for them, applications that I built and maintained have always been Java Swing. When it comes to the codes, I know them quite well since I almost single-handedly built them.
When it comes to Swing and DDD, there aren’t many resources — I dare say, none — to help me. I mean it’s pretty obvious right? It has “over-engineering” written all over. Anyway, I had to figure out some things on my own in order to achieve what I want to do.
In terms of implementing DDD, how a project is structured is entirely up to you, your project team, and/or your organization. Hexagonal architecture might be a better choice in many situations. In my case, I found myself liking the project structure of the Sample Cargo Project (dddsample). In my opinion, it’s clean but I do know it does not work in all cases. For this blog series, I will be using this structure. Feel free to experiment with other architecture style if you are up for it.
In the dddsample project source codes are arranged into four main packages: Interfaces, Applications, Domain, and Infrastructure.
The Interfaces package generally contains all the necessary codes and implementation to support rendering of information or data and receiving inputs such as file uploads. DTOs, remote service facades and assemblers typically reside in this package too.
The Application package contains all the necessary codes and implementations necessary to fulfill use-cases and are treated as APIs to be used by the Interfaces. It’s also where auditing, transaction and logging are done. This is also where your application services reside.
The Domain package is where all the core business rules (domain services), behaviors, entities, and value objects reside. Repository pattern also come into play here.
Lastly is the Infrastructure package. This is where you get technical. Codes here are generally the implementation of domain services. For example, the application needs to talk to some external systems through web services or RPC in order to fulfill the business request or compute business rules. It’s also where database implementation take place. As the word suggest, the things here are meant to support the execution of the application. Therefore, you should also put any other codes or configuration files in this package.
I will end part 1 here. In the next part, I will be talking on how I actually apply DDD to a Swing application. I will be creating the demo using NetBeans 8.2 and going with the default empty Java application option.