Having decided to catch up with JavaFX, I thought about what to code. Like many developers, I used to play games a lot. Open-world games in which the world is developing itself and the player is just a part of it have always fascinated me. So I decided to code one on my own. In my simulation, there should be some natural eco system like growing ressources. These ressources should be used by some developing culture. As you see, my ideas are pretty rough and abstract at this time. I will make up my mind in the process of coding, so don’t expect my decisions to follow a clear path.
The main goal of this exercise is to learn JavaFX and, in the process, do some software engineering. I will document my architecture decisions and think (i.e. blog) about my experiences during development. Hence, this is the first of a series of articles about what I will call “SimFX”. This working title elaborates my plans: An open-world simulation with JavaFX.
First Architecture Decision
According to Stefan Zörner, the architecture of an application is the sum of decisions that can not be taken back easily in the further process of development. The main source of problems in later phases of development are the non-existing documentations about these decisions. It is not enough to stipulate the final decision; the process which led to that decision has to be documented, too. This way, new developers in the team can understand the basic decisions easily and can also comprehend, why certain alternatives weren’t choosen. I agree with Stefans thoughts because I myself have often been asking questions about legacy systems and was answered often enough the famous sentence “This evolved over time”. Of course, this statement has absolutely no value to a newbie.
At this early point, I made one important decisions that I want to document here.
As I said, the main goal of this project is to code some JavaFX. Maybe I want to port the application to another UI framework in the future to deepen my understanding of that framework without having to write a whole new business logic. This raises the question how the structure of the application should look like to be able to switch the frontend in the future.
After having defined the problem (“How to structure the application to be able to switch the frontend in the future?”), the limiting factors have to be researched. I already choose to code the business logic in Java and I want to reuse this logic for every new UI. Hence, I can only port to frontends for systems that are capable of running Java, too. This shouldn’t be a problem because my target platforms are most likely PCs that run Windows or Linux. This is the only technical limitation I can think of right now … did I miss something?
The third part of documenting a decision is to write down the assumptions. Concerning the exchangable UI, I assume that UI frameworks are easy to decouple from the business logic. The opposite of this would be a framework that totally controlls the execution path of an application.
I also assume that all frameworks I want to use in the future have different APIs. Hence, there has to be an intermediary part of the application that bridges the gap between my business logic and the API of the UI framework.
The second and last assumption concerns the risks of isolating the business logic from the UI. There sure is the risk that I will never implement another UI, which would render the separation logic and the intermediary part useless. If this becomes reality sometime, this part of the architecture was just a finger exercise.
The fourth part of the decision is thinking about alternatives. The only alternative to isolating the business logic from the UI is not to do so. I simply reject that alternative.
The last step in the documentation is to decide: I hereby decide that there should be some kind of adapter that separates the UI from the business logic. Hence, the overall architecture has to look something like this:
So, what do you think of this project? Are my thoughts concerning the architecture comprehensible?