Tomasz Fijałkowski's programming blog.
In a Quick introduction to Java 9 modularization article I quickly introduce the basic concept of a Java 9 modularization. Now is the time to improve modules design. In this article we will focus on reducing modules coupling.
The new version of the Java is fast approaching. The official release is scheduled for the 27 of July 2017. However, you can already use the early access version to play with the new features. In this post, I’d like to quickly introduce the modularization of the Java 9.
If I had to mention two things that can change the fate of the project, it would have been domain-driven design (DDD) and agile methodology. One of the most popular agile methodology is Scrum which provides product owner role. Unfortunately, I noticed that in many projects, the weakest link of the team was a product owner. This is not because they are generally bad product owners, it’s possible that in other projects they could do a great job. Although it seems obvious, not everyone realizes that the product owner should be the domain expert. Otherwise, She/He can be just a proxy to clients. This is a very uncomfortable situation. A team meetings, for example, often end up with the statement “I have to ask the client, can we finish tomorrow?”. This leads to a delay in the project and a decline in morale. To prevent that, developers skip the product owner and speak directly with the client. It degrades the product owner role to a secretary who adds meetings to a calendar, reserves the room, and so on. However, the essence of process is lost, DDD approach can’t by mixed with scrum methodology when product owner doesn’t known the core domain.
Microservice-base architecture gains in popularity every day. This approach has many advantages. The most important advantages include: independent deployments, shortened and simplified deploy pipeline, limited communication between teams, and technology freedom. These core advantages support quick delivery of new features. Microservices, of course, bring also a lot of challenges. Wrong approach can ruin all microservices benefits. It can also transform the architecture to some kind of rotten architecture which I call distributed monolith or micro-monolith anti-pattern. Following situations are the symptoms of anti-pattern occurrence:
Many times I heard that the microservice-based architecture is a solution of modularization issue. This is explained by the statement that monolith is a pure evil with the big ball of mud architecture. Microservices, in contrast, are well separated units of business logic. This biassed point of view is visualized by diagrams like
Understanding data model is sufficient to design good database schema in RDBMS (relational database management system). Having this knowledge you are able to construct normalized tables, add appropriate constraints and finally create indexes to speed up queries. In the world of NoSQL there are no simple solutions, rules and answers. That’s why we can only talk about patterns, tips and hints. MongoDB is not an exception. Besides the comprehension of stored data, deep understanding of an access pattern, how data is searched, inserted and updated by an application is needed.
In its early days, Java has a wide uses of checked exceptions. However, lazy nature of programmers triggered trend to abandonment checked exceptions to unchecked exceptions. This approach causes negligence an error handling and hiding side effects. Additionally exceptions catching is not checked at compilation level.
Java 8 supplies a lot new useful features, unfortunately also new misunderstandings and antipatterns are observed every day. One of that mistake is a wrong use of default method in interfaces.