DEV Community: Cristian Olaru

Java Number One in 2019?

Cristian Olaru — Mon, 23 Dec 2019 10:24:26 +0000

End of the year! Some facts about Java in 2019! Is it good? Is it bad? Your thoughts?

In 2019 Java is still number one on Tiobe index - https://www.tiobe.com/tiobe-index

Oracle Java One conference is now renamed to Code One

Android is Kotlin first announced by Google. Google will deliver the Android APIs first in Kotlin and after this in Java

Refactoring 2 by Martin Fowler has the samples in JavaScript and not Java, like in the first version of the book

Pivotal (Spring) was acquired by VMware

RedHat (JBoss) was acquired by IBM

Java EE is JAKARTA EE now out of Oracle garden and in the Eclipse Foundation - https://jakarta.ee

Oracle refuses to let the javax package to be used by Jakarta

September 2019 → Java 13 in many distributions: https://sdkman.io/jdks (but everyone I know is still blocked at Java 8)

For 2020

Oracle Code One Is Moving to Las Vegas -> September 21–24, 2020!
Pivortal Spring One Will be in Seattle -> September 21–24, 2020!

Clean Architecture - a short book review

Cristian Olaru — Tue, 13 Aug 2019 19:50:04 +0000

This is a review for the Clean Architecture book written by Uncle Bob (for the first three parts). I read it on my holidays, and I must confess is not what I can name a 'holidays book'. This, because it is a very serious book about programming written by someone with more than 50 years in this field - that 50 years of programming history are reflected everywhere in this book. You need some quiet place to reflect about it, and a net connection to browse additional material.

First, I will make a description of the book parts with the essential aspects discussed. In the end, I will express my feelings and impressions about the content.

PART 1 - Introduction

Design and architecture are the same - architecture is sometimes considered to be the structuring at the high level of the system and design to be the structuring of the low level of the system. Both are architecture!

The goal of architecture is to 'minimise the human resources required to build and maintain the required system'. The author gives an example of a wrong application, where for release 8, the code was 40 times more expensive to produce than in release 1.

The software provides two values to the stakeholders: behaviour and structure. The developers have the responsibility to keep both these values high. The software has to be 'soft' = easy to be changed and maintained. That's why the structure = architecture is essential.

PART 2 - Programming Paradigms

This part of the book is dedicated to the programming paradigms. There are three paradigms that are discovered between 1958 and 1968, and no paradigms were discovered in the following decades. This is a sign that these are all we can have:

Structured programming = programming based just on these structures of control: sequence, selection and iteration. 'Go To statement considered Harmful' article of Dijkstra imposed the 'discipline on direct transfer of control' - jumps from one line of code to others are evil and are not needed.

Object Oriented programming - in ALGOL the class/object concept was born = the function call stack frame can be moved in Heap, the function can become the class constructor, and the inner functions can be the class methods.

The essence of OO consists not in the ability to model the world with objects - 'everything is an object' - but by the benefits of OO: encapsulation, inheritance and polymorphism. While encapsulation, inheritance and polymorphism can be achieved in non-POO languages, in POO these are more simple or even trivial to be expressed.

And especially the polymorphism is giving us dependency inversion = absolute control of all source code dependencies in the system → independent deployability → independent develop-ability. OO polymorphism imposes 'discipline on indirect transfer of control'.

Functional programming - variables in a functional language do not vary = are immutable. This is a big advantage because all the concurrent problems are because of mutable variables.

One idea is to use a technique named 'event sourcing' = to evict the update/delete operations (CR from CRUD) and to keep a ledger of events like in accounting - anytime we can recalculate the state from events. Functional programming is about 'discipline imposed upon variable assignment.'

As a conclusion, the software these days is composed of sequence, selection, iteration and indirection. The hardware changed drastically in time, but the software remains the same as in the first days of programming.

Part 3 - Design Principles

Here is a description of the SOLID principles seen from the architecture point of view. SOLID is about how to arrange our functions and data into classes and how classes should be interconnected like 'bricks in the walls'. The next part will talk about how to structure components in the systems = 'rooms in the buildings'.

These principles are used to create structures 'bricks in the walls' that tolerate change and make the code easy to understand = the global scope of design/architecture.

The principles:

Single Responsibility Principle

A module should have one, and only one reason to change. More precise, to only one actor: user or stakeholder. The classical solution for this problem is to split into more functions/classes.

Open/Closed Principle

A software artefact should be open for extension but closed for modifications. An example is shown about how we can protect higher-level components from changes in lower-level components.

Liskov Substitution Principle

Barbara Liskov (1988) If for each object o1 of type S there is an object o2 of type T such for all programs P defined in terms of T, the behaviour of P is unchanged when o1 is substituted for o2 then S is a subtype of T. The author is using the classical rectangle-square problem to reflect the principle.

Interface Segregation Principle

Depending on something that carries baggage that you don't need can cause you troubles. So split the interfaces in pieces and in this way you will evict inutile recompilations and redeployments.

Dependency Inversion Principle

Interfaces are less volatile than implementations. So don't refer to volatile concrete classes, but interfaces. The author shows an Abstract Factory pattern implementation for illustrating the dependency inversion.

My ideas(maybe not so well articulated, so you can skip this part)

Three in one coffee

I think the tendency in modern languages is to have all three programming paradigms inside - structural, OO and functional. For example, Java has structural control blocks similar to the C language. It is OO by design. And in these days it has functional support starting with Java 8 lambda functions and streams (functional also with Groovy support). Javascript (another language that I am interested in) is structural at ES5 level, and become OO at ES6, and can be used in a functional style with libraries like Underscore.JS and Lodash JS.

First time I saw a computer and I wrote a program

I miss 30 years of experience from my uncle Bob's history - that's why we need an uncle to tell us stories about the past!

I started to use Java in the 2000s, and it was my primary programming language till now. My feeling is that we had two waves of POO. First was C++ and Objective C, where we still can see pointers and references to the machine. The second wave was Java and C# with Virtual Machines (JVM and CLR), Garbage Collectors, and no pointers. These were high-level programming language where we think just in objects - without any reference to the machine in our code (Threads, Sockets, etc. are OS-specific and are modelled as objects). Will fill the machine maybe, just when we start the JVM, and we configure the memory, GC type.

But the first language I learned in school was BASIC in the '90s, and it has GOTO, and there I was giving numbers to the lines, and I remember I used to jump from one line to another - imperative programming we named it. The second main language in school was PASCAL - structured programming (procedural).

In that time the Z80 (Zilog) processors were used at home with 64K memory - x86 (Intel/AMD) was already seen as the future but were too expensive at that time to have one at home - still remember first 486, and 586 (Pentium) we have at school. I still remember those games on tapes we used to play all day. I do some assembly language subroutines also on Z80 inspired by the games.

Typed/dynamic languages debate

I think a subject of the programming history is also the typed/dynamic typed dispute in languages. See the languages from the last time (Scala, Groovy). Static compile checked languages like Java, TypeScript versus runtime dynamic languages like Groovy (also running on JVM) or JavaScript. The tendency of dynamic languages to be scripting oriented - a lot of semantic in a concise syntax.

Functional means just immutability?

Not sure what is the essence of functional programming (if immutability) - I think that the possibility to apply a function to a data structure, to make chain of functions in a declarative way, to have the function as a citizen of the language passing it as a parameter - to do all this map/reduce stuff that is hard to be done in structured programming.

Immutability is not the single way to simplify the concurrency problems (locks, pools of threads). Event loops/single-threaded per core programming like Node.JS/Vertex can help as to escape from classical concurrency problems (works hand in hand with non-blocking but is imposing you to have all your system modelled by small non-blocking events - or use workers for long time jobs).

The Software Craftsman - a short book review

Cristian Olaru — Sat, 03 Aug 2019 07:37:11 +0000

I use to take a book with me on holidays to read something interesting. There are some moments on my holidays when I have some time to read. Especially when I am waiting for the plane, I am in the flight time or on the beaches under the Spanish sun.

This holidays I took with me The Software Craftsman - Professionalism, Pragmatism, Pride written by Sandro Mancuso. I thought it would take the entire holidays to read the book. I was wrong because I read it in 4 days because it catches me.

From far, it is the best book I read this year - even it doesn't have one line of code. Maybe from the way it is written with short real-life stories from the author career, many am them being a "deja vu" for me.

I also correlated this book content with this fascinating Uncle Bob Martin video presentation - The Future of Programming, which is the past and the future of programming. I also read this article at the same time and is the first time when I heard about planes crashing because of outsourcing software. The material is this Boeing’s 737 Max Software Outsourced to $9-an-hour Engineers.

Book structure

I will introduce the book chapters with a single main idea I liked most in each section.

The first part is a retrospective of the current state of works in the programming.

Software Development in the twenty-first century - seniority in the 90s "writing code that no one else could understand would make you a senior developer straight-away."
Agile - Agile transformation is fake because "project managers become Scrum masters. And agile became the new name of the old way of working"
Software Craftsmanship - introduction and explanations of the Software Craftsmanship manifesto
The Software Craftsmanship attitude - about keeping ourselves up to date
Working software - "working software is not enough" and why "developers are scared to touch the existing code" to add new features
Heroes, Goodwill, and Professionalism - learning how to say "no" and give alternatives (no .. but)
Technical practices - introducing XP practices
The long road - "assuming that money is off the table - knowledge workers are motivated by three things: autonomy, mastery and purpose."

The second part is about the actions we have to do to exit from the current state.

Recruitment - First three chapters are about recruiting because it is the first steps for changing something
Interviewing Software Craftsmen - "interviews are a two-way street."
Interview anti-patterns - don't make the candidate look like a fool
The cost of low morale - how we lose it and how we can recover it injecting passion
Culture of learning - we have to create a culture of learning in our company
Driving technical changes - sceptics: the uninformed, the herd, the cynic, the burned, the time-crunched, the boss, the irrational, the indifferent, the wronged, the inept, the ivory-tower architect, the insecure, the fanboy
Pragmatic Craftsmanship - '... to be able to change the code almost as quietly they change their minds'
A career as a software craftsman - passion is the main word

Some random ideas

I try to expose here what impressed me much on this book in no given order.

Outsourcing problems

I was impressed by the story of the author experience in Brazil working in an outsourcing company. There he was forced to slip in his car in the company parking because he didn't have enough time to commute because of the overtime. And his colleagues were coming to him in the night to ask questions about the project.

Outsourcing projects problems:

the wrong way of thinking that the diagrams and specs are the only important thing because writing code is simple, and the developers are not important and they are like factory workers
the wrong idea that we will stay in our cubicles, and we will produce beautiful specifications for the teams over the sees - and they will create our fantastic product

The old way of writing code like in the '90s (still practised by many today)

** cryptic writing code** similar with the algorithms we lean in school and the IDE debugger used on day by day basis
the wrong practice of writing generic code to the extreme and never write specific code is also something that originated in the school (it's a kind of premature optimisation)
the code can be written so unclean, so we became afraid to make changes even with all these extraordinary refactoring tools we have today in the IDEs
and the things are going from wrong to worse as time is passing; first that will leave are the good devs; the rest will stay and will make the tragedy bigger

Career inside companies

many people are entering in political games wanting to become part of the management instead of being software craftsmen
that's why someone from Eastern Europe is saying that if you are over 30, and you are a developer in the company than you are failure
Sometimes we have to say "no" to management; in fact, we have to give alternatives: "no ... but"
the sceptic typologies of people from companies resisting to change are very well described: the uninformed, the herd, the cynic, the burned, the time-crunched, the boss, the irrational, the indifferent, the wronged, the inept, the ivory-tower architect, the insecure, the fanboy
the problem of treating the programmers as factory workers

Scrum and XP

Scrum process is about "made the right software" vs XP techniques are about "made the software right."

a balance between the two is needed
Scrum was not well adopted (because managers are becoming scrum masters, certifications to be considered enough, etc.)
Scrum and Lean Startup is giving value for the business

Inspirational resources links

The future of programming - https://www.youtube.com/watch?v=ecIWPzGEbFc
Boeing accident - https://www.bloomberg.com/news/articles/2019-06-28/boeing-s-737-max-software-outsourced-to-9-an-hour-engineers
Extreme Programming - http://www.extremeprogramming.org/

GraphQL - The REST is over

Cristian Olaru — Wed, 31 Jul 2019 11:11:29 +0000

Overview

In the last years, I was very happy exposing REST Web Services consumed by Angular JS clients (and using Swagger for documenting the API). But it was a situation in the last year when we had a huge data model with hundreds of entities exposed as REST resources. In that case, the REST was not enough. So, my rest was over - I started to search for a better way to expose and consume web services and I found something named GraphQL.

This doesn't mean that REST is over. A GraphQL API can stand in front of a REST API or the tho APIs can coexist at the same time. The idea is that there is a new way of consuming/exposing an API. It is better in the case we have a schema on the server-side. There is GraphQL For The Rest of Us

Image credit http://howtographql.com

The application story

The application was a classical client-server app with Java/EJB in the backend exposing a set of JAX-RS REST web services to an Angular client. We used JPA for persistence and we modeled the entire graph of entities using JPA annotations.

We split the domain in some aggregates with dozen of classes and with an aggregate root - mainly using IDs as fields instead of foreign keys. We exposed an end-point for some aggregate roots - in a rest-full way. The requirement of the project was to expose just CRUD operations in our endpoints (of corse not CRUD wasn't enough) because the business flows are part of the client application. This was good because we can respect the REST principle of having resources (NOUNS) with the state modified by the HTTP commands (VERBS).

We used Swagger for documented the API - the frontend team was able to call our API from Swagger UI in realtime. The Swagger/Open API documentation was generated dynamically from the annotated endpoints. The Angular front-end was generating the TypeScript client from Swagger using its code generation facilities. Everything seems to be fine.

But something wasn't all right. Our JPA entities are also our REST resources. In JPA the entities are linked together in a graph according to the database schema. When we get the aggregate root, we get the entire graph of entities with all fields. And because the entities are the resources the client is receiving a huge JSON file each time. Usually, in the Angular components, not the entire graph was needed, and not all the fields of the resources.

What we will do if we have a data model like in this story, a data model in which the company invested years to create. What we will do if we have a model like this GitHub data model:

Image credit: howtographql.com

There are a few patches

One is to use some annotation from the marshaling/un-marshaling framework @JsonIgnore, @XmlTransient on our entities to simplify the JSON received by the client. This is problematic because in some endpoints we need to send to the client some fields of the resources in other cases different fields - annotating the entities/resources will suppress the fields for all client calls.

Another solution is to create different WS endpoints and to hide some fields when we sent a response to the client. To use for example a different package of resources different from the domain entities and to populate them from entities when we send back the response. This is also problematic because we introduce more complexity - our API will be more in the RPC style (not REST) and we will have extra work in populating the resources from entities. And we have to write Named Queries or Criteria Queries to fetch the right data from the database and not just CRUD operations.

The last solution I know is to have real isolated resources and not graphs of objects exposed on the server-side. In this case, we will have multiple calls maybe 1+n calls on the cases of collections. So this is also a problem because of the multitude of calls we have to do.

The REST is not enough

This kind of project from the previews story shown a downside of the REST - it is not good for this case when we have a rich domain on the server-side - a graph of objects. In this case, the generated JSON is huge and enriched with un-necessary information. The solutions to solve this problem will lead us out of the REST style to remote procedures calls (RPC). Or to complicate the backend using some extra code - not use just simple ORM CRUD operations.

For these cases, it seems that GraphQL is the solution. We will ask the server just for the pice of information we need. Because we don't want the entire schema. REST is fine when we have isolated pieces of information like system messages, notifications. But is not good for the case we have a big schema.

And schemas are everywhere - documents (XML, PDF, JSON), the file/folders file systems, relational databases (even if is a forced schema), DOM, etc. REST is ok for non-relational databases (MONGO-DB) where we have collections of entities. But is a relational database we store a graph of objects (even if we do this in a forced way). That's how we store the majority of the data we have now.

Introducing GraphQL

GraphQL was born from the effort of the Facebook team to accommodate the application to the modern world of mobiles. It is used inside Facebook along with other technologies like React or Jest, also invented by this company. The complete story can be found in this GraphQL original documentary, presented by the developers of the technology.

GraphQL was at the beginning just a specification about how to interact with the data from the client perspective in a declarative way. First, a reference implementation was created for Java Script, and other developers started to implement it on other programming languages. It is not a way to expose an API on the server-side, but a way to consume data from the client-side. It doesn't specify the dataset that is exposed if it is a database or a REST API. It doesn't specify the communication protocol that is used - if it is HTTP or not!

GraphQL provides a method to document the API, a way to specify the API capabilities named Schema. Historically speaking, we have GraphQL/Schema as we have SOAP/WSDL, REST/Swagger-OpenAPI. We can start from this schema to generate de client or the server in the same way we do with the other types of web services APIs (REST or SOAP).

Steps to learn GraphQL

First watch this video named GraphQL - The documentary to understand how, when and why this technology was born
Learn as match you can from these GraphQL video tutorials
Make some real calls with an existing UI client and on an real online APIs
Study the support for GraphQL in your preferred programming language
Implement an API on a simple schema
Read the GraphQL spec
See how Gatsby.js implements the source and transformers plugins

Gatsby.js vision

I can't finish this article without saying something about Gatsby.js. Why can I name it the next WordPress? Because it has everything, Wordpress has a pluggable system with themes, easy to extend by developers, based on the right abstractions. It is a way to create micro frontends combining React components with GraphQL schemas.

To be honest, I dreamed of this for a long time in the form of a combination of Web Components and Microservices - but it seems that React/GraphQL is offering this under the Gatsby.js umbrella right now when you read this.

Gatsby is offering a good option to create static progressive web apps. For the GraphQL part, Gatsby is offering a set of sources and transformers plugins that are letting you pull data from headless CMSs, SaaS services, APIs, databases, your file system or any other source.

Inspirational Resources Links

GraphQL documentation

GraphQL documentary - https://youtu.be/783ccP__No8
Technology site -https://graphql.org/
How to GraphQL - https://www.howtographql.com/
Introduction to GraphQL - https://graphql.org/learn/
Play with online GraphQL APIs - https://www.graphqlhub.com/
Build FB with React, GraphQL and Relay - https://www.youtube.com/watch?v=WxPtYJRjLL0
GraphQL-conference -https://www.graphqlconf.org/
Awesome GraphQL GitHub - https://github.com/chentsulin/awesome-graphql

Client support

Apolo Client - https://github.com/apollographql/apollo-client
Relay Client - https://relay.dev/

Server support

Spring Boot Server support - https://www.pluralsight.com/guides/building-a-graphql-server-with-spring-boot
Grails Gorm Server support - https://grails.github.io/gorm-graphql/snapshot/guide/index.html

IDE/UI Clients

Voyager Client - https://apis.guru/graphql-voyager/
GraphiQL Client - https://github.com/graphql/graphiql
GraphiQL Client Electron packaged - https://electronjs.org/apps/graphiql
Playground Client - https://github.com/prisma/graphql-playground
Altair Client - https://altair.sirmuel.design/

Micro frontends

Micro Frontends - https://micro-frontends.org/
Micro Frontend Martin Fowler - https://martinfowler.com/articles/micro-frontends.html

Gatsby

Gatsby static site generator - https://www.gatsbyjs.org/
Gatsby source plugins - https://www.gatsbyjs.org/plugins/?=source

Others

Rest components - https://github.com/brillout/awesome-react-components/blob/master/README.md

Creating a Domain Model rapidly with Java and Spring Boot

Cristian Olaru — Thu, 18 Jul 2019 07:02:52 +0000

Overview

In this short article, we are creating a domain model for a simple application. We illustrate how we are creating the classes/objects of the model, based on the application business description. We insist just on the entities that are part of the model.

Here we talk about domain modeling in the case of a Web application with a client-server architecture where we have Java on the server-side (backend). All the examples are in Java language. We use Spring Boot to accelerate the application startup.

Start the implementation

Tools we are using:

Java 8 JDK from AdoptOpenJDK installed with SdkMan
SpringBoot - just for starting rapidly an app with integrated build using Spring Starter
Maven - used internally for build
JUnit - used for playing with the domain
Intellij Idea - for code editing (you can use VS Code or Sublime)

If you are on Windows OS then the Java JDK 8 can be installed manually and also Maven can be installed manually. Spring Initializr -https://start.spring.io can be used to download the Spring Boot starter app. But on MAC OS and Linux, the fastest way is to use the terminal commands as you can see after.

Starting our app (we name it cindykat - a name very close to syndicate) and running it is is just like this:

# install SDKMAN
curl -s "https://get.sdkman.io" | bash
# install JDK
sdk install 8.0.212.j9-adpt
# create app
curl https://start.spring.io/starter.zip -d name=CindyKat -d groupId=com.colaru -d artifactIf=cindykat -d packageName=com.colaru.cindykat -d dependencies=web -d javaVersion=8 -o cindykat-springboot.zip
# unzip, then run it
unzip cindykat-springboot.zip -d cindykat-springboot
cd cindykat-springboot && ./mvnw spring-boot:run

Now our app is up and running on 8080 - it is a web application! No need for a web app - is ok to have something up and running.

We have this project structure:

What is the application domain?

The domain model is the place in our code, where we are modelling the business of our app. Usually, an application model has to be a direct reflection of the business it implements. Our code has to be a story of the reality we are modelling. And we have to use a ubiquitous language used by all people working on the project.

That's no need to introduce other abstractions different than what we have in the reality we are modelling. The nouns and verbs from the business have to appear in the name of our classes, fields, methods. When we introduce other things - we can be suspected of over-engineering.

Image source: https://www.slideshare.net/Dennis_Traub/dotnetcologne2013-ddd

Why is the model so important? Because all the rest of the application will be in contact with the model. It is hard to have separate packages of DTOs or WS REST resources or persistence entities because of the marshalling/un-marshalling complications. We will be forced to do this if we don't want to expose the internal model outside the system. So we will use the model in all the layers of the application. You can be sure that the UI, persistence, reporting, WS, messaging integrations, all are using the domain model classes.

And the model can become more an more complicated over time (hundreds of classes). And what is in the model will evolve and will influence the entire application. This is the hardest part to be understood in any app by a new development team joiner. Here is not something like a library or framework reused in other applications, but here is something specific to a business. And the businesses can be very, very complicated.

The DDD book

There are a few ways of starting a Java Web application:

Backend first - play with the Java domain using tests to create a domain model that is the core of the server-side
Frontend first - start with UX/UI with HTML/ CSS/ JavaScript and create some mockups that will illustrate the user interaction - you can play with a domain model in JSON or Typescript here also

It is common to have a team that is working in the frontend, and a different team that is working in the backend and the contract between them is a Swagger/Open API spec.

The first approach, modelling the domain, is the subject of this article. And is the subject also of a very well known book: Domain-Driven Design by Eric Evans. In this book, more topics are introduced apart from the graph entities described in this article.

Image from Domain Driven Design Quickly book

Our application business explained

The application we want to implement is an analytics system for the data provided by Google Trending Searches - The history of searches from Google Search reported per day and country by Google. We want to import some data from Google Trends, then store it in our system and make it possible to analyse it, show it in a different form, etc.

In this case, it will be simple to model our domain used in our analytics system. Because we are distingue our entities from the format used to get the searches data. See this Google Trends Atom Syndication Format XML snippet:

        <item>
            <title>Women's World Cup 2019</title>
            <ht:approx_traffic>1,000,000+</ht:approx_traffic>
            <description>2019 Women, Women World Cup, WWC</description>
            <link>https://trends.google.com/trends/trendingsearches/daily?geo=US#Women's%20World%20Cup%202019</link>
            <pubDate>Mon, 10 Jun 2019 22:00:00 -0700</pubDate>
            <ht:picture>https://t2.gstatic.com/images?q=tbn:ANd9GcTW4UzPHNC9qjHRxBr6kCUEns71l8XK6HYcmLpJbhlfZWUbeBQPiia1GDzN3Ehl7nfD-HPbgnG_</ht:picture>
            <ht:picture_source>CBSSports.com</ht:picture_source>
            <ht:news_item>
                <ht:news_item_title>&lt;b&gt;2019 Women&amp;#39;s World Cup&lt;/b&gt; scores, highlights: Canada squeaks by, Japan underwhelms, Argentina gets historic point</ht:news_item_title>
                <ht:news_item_snippet>Day 4 of the &lt;b&gt;2019&lt;/b&gt; FIFA &lt;b&gt;Women&amp;#39;s World Cup&lt;/b&gt; in France featured a two-game slate with two potential contenders opening their campaigns against slightly inferior opponents. When the dust settled, neither team looked particularly sharp as only one goal was&amp;nbsp;...</ht:news_item_snippet>
                <ht:news_item_url>https://www.cbssports.com/soccer/world-cup/news/2019-womens-world-cup-scores-highlights-canada-squeaks-by-japan-underwhelms-argentina-gets-historic-point/</ht:news_item_url>
                <ht:news_item_source>CBSSports.com</ht:news_item_source>
            </ht:news_item>
            <ht:news_item>
                <ht:news_item_title>&lt;b&gt;2019 Women&amp;#39;s World Cup&lt;/b&gt; scores, highlights, recap: Japan underwhelms in opener as Argentina gets historic point</ht:news_item_title>
                <ht:news_item_snippet>Day 4 of the &lt;b&gt;2019 World Cup&lt;/b&gt; has a small slate of action with just two games, but two contenders to win the tournament were scheduled to play their opener. After the first match, we may just be talking about one contender. With talented Canada set to play&amp;nbsp;...</ht:news_item_snippet>
                <ht:news_item_url>https://www.cbssports.com/soccer/world-cup/news/2019-womens-world-cup-scores-highlights-recap-japan-underwhelms-in-opener-as-argentina-gets-historic-point/</ht:news_item_url>
                <ht:news_item_source>CBSSports.com</ht:news_item_source>
            </ht:news_item>
        </item>

So it is simple! We have an Item which has a list of NewsItem. We separately have a Source entity that will be reused between NewsItem. Also, a Country is needed for the Item specify the country/language. That's all.

Creating the graph of entities

The domain model will be a separate package in our application. We choose to create a sub-domain named newsfeed (complete name com.colaru.cindykat.domain.newsfeed) for naming the package because it is possible to have other aggregates (groups of entities) in the future.

It is a good idea to create an entire module for the domain (in a multi-module Maven/Gradle project) because in this way we can create a dependency to it in any other modules of the application - all the other modules will use the domain model.

First, using the IDE, we will create an Item class, which is the primary entity (aggregate root in DDD terminology) and then the rest of the classes:

package com.colaru.cindykat.domain.newsfeed;

import java.util.Date;
import java.util.List;

public class Item {

    private String title;
    private List<Tag> description;
    private String link;
    private String picture;

    private Date pubDate;
    private String pubDateAsString;

    private String approxTraffic;
    private Long approxTrafficAsNumber;

    private List<NewsItem> items;
    private Country country;

    // generate getters/setters using the IDE
}



public class NewsItem {
    private String title;
    private String snippet;
    private String url;
    private Source source;
}


public class NewsItem {
    private String title;
    private String snippet;
    private String url;
    private Source source;
}

public class Country {
    private String name;
    private String countryCode;
    private String languageCode;
    private String flag;
}

public class Source {
    private String name;
    private String url;
}

public class Tag {
    private String name;
}

In the end, we will have this graph of entities:

Now the project filesystem is like this:

Anemic Domain

A common problem for a domain is an anti-pattern named Anemic Domain by Martin Fowler - the classes are having just state and not behaviour. We get from the real word only the nouns and not the verbs. In this case, the entities are data structures like in the functional programming language and not real Java objects as Uncle Bob is describing in this article. And this is something normal because in general, the entities are our mappers to database tables used by an ORM persistence framework.

We expect that the verbs will be in the services layer of our application outside the domain. But in this case another discussion is starting: are this services part of the domain?

But also there it is no problem to introduce some logic directly in the entities - in this case, we have to be aware that we will have business logic in two places: services and in the domain model.

We will introduce some business methods in the Item entity (some convertors from String to Date and from String to Long):

public class Item {
        private Date pubDate;
    private String pubDateAsString;
    private String approxTraffic;
    private Long approxTrafficAsNumber;

    // other private fields

    public Date convertStringToDate(String pubDateAsString) throws ParseException {
        SimpleDateFormat parser = new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss Z"); // Wed, 21 Dec 2016 13:00:00 +0200
        return parser.parse(pubDateAsString);
    }

    public Long convertStringToLong(String approxTraffic) {
        return new Long(approxTraffic.toString().replaceAll(",", "").replace("+", ""));
    }
}

Testing the domain

Even if the domain is simple, it is a good idea to start playing with it using and creating some tests using JUnit. First, we have to include the JUnit library as part of our Maven dependencies in pom.xml:

    <!-- https://mvnrepository.com/artifact/org.junit.jupiter/junit-jupiter-api -->
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter-api</artifactId>
        <version>5.3.2</version>
        <scope>test</scope>
    </dependency>

Now we can create a first test to play with our simple graph of objects and to verify some small functionalities. This is a first working skeleton good enough to start our TDD development guided by tests for the next features we will add to this app:

class DomainModelTests {

    private Item item;

    @BeforeEach
    void setUp() throws ParseException {
        item = new Item();
        item.setTitle("Women's World Cup 2019");

        item.setLink("https://trends.google.com/trends/trendingsearches/daily?geo=US#Women's%20World%20Cup%202019");
        item.setPicture("https://t2.gstatic.com/images?q=tbn:ANd9GcTW4UzPHNC9qjHRxBr6kCUEns71l8XK6HYcmLpJbhlfZWUbeBQPiia1GDzN3Ehl7nfD-HPbgnG_");

        // tags
        Tag tag = new Tag();
        tag.setName("Word cup");
        List<Tag> tags = new ArrayList<>();
        tags.add(tag);
        item.setDescription(tags);

        NewsItem newsItem = new NewsItem();
        // source
        Source source = new Source();
        source.setName("USA TODAY");
        newsItem.setSource(source);
        newsItem.setTitle("&lt;b&gt;2019 Women&amp;#39;s World Cup&lt;/b&gt; scores, highlights: Canada squeaks by, Japan underwhelms, Argentina gets historic point");
        List<NewsItem> items = new ArrayList<>();
        items.add(newsItem);
        item.setItems(items);
    }

    @Test
    void buildNewItemTest()  {
        Assert.assertEquals(1, item.getItems().size());
        Assert.assertEquals(1, item.getDescription().size());
    }

    @Test
    void convertStringToLongTest() {
        String approxTraffic = "900,000+";
        item.setApproxTraffic(approxTraffic);
        item.setApproxTrafficAsNumber(item.convertStringToLong(approxTraffic));
        Assert.assertEquals(900000, item.getApproxTrafficAsNumber().longValue());
    }

    @Test
    void convertStringToDateTest() {
        String pubDateAsString = "Mon, 1 Jun 2020 09:00:00 -0700";
        item.setPubDateAsString(pubDateAsString);
        try {
            item.setPubDate(item.convertStringToDate(pubDateAsString));
        } catch (ParseException e) {
            e.printStackTrace();
        }
        Calendar cal = new Calendar.Builder().setCalendarType("iso8601")
                .setFields(YEAR, 2020, DAY_OF_MONTH, 1, MONTH, 5, HOUR, 18, MINUTE, 0, SECOND, 0)
                .build();

        Assert.assertEquals(cal.getTime(), item.getPubDate());
    }
}

When we run all the test the bar is green (I write the test first, then the tested method, the test run is failing, I add the implementation, I run the test again, and now it is passing):

Conclusion

In this article, we've exposed how we created a simple model for a small application.

As we can see, the domain model is the core part of the application. This classes that are composing the domain model are technology agnostic (concurrency, persistence is not in our interest now) - are describing just the reality of the business - nothing regarding the technologies used in the project.

Git Repository

We published the sources on GitHub:

git clone https://github.com/colaru/cindykat-springboot.git
cd cindykat-springboot
mvn clean install // the tests will be executed successfully

You can follow me on Twitter where I continue to document my journey.

Inspiration links for this article

Value objects vs entities: https://enterprisecraftsmanship.com/2016/01/11/entity-vs-value-object-the-ultimate-list-of-differences/
Anemic domain: https://martinfowler.com/bliki/AnemicDomainModel.html
Domain services: https://stackoverflow.com/questions/2268699/domain-driven-design-domain-service-application-service
Domain model: https://martinfowler.com/eaaCatalog/domainModel.html
Service layer: https://martinfowler.com/eaaCatalog/serviceLayer.html
Objects and data structures: https://blog.cleancoder.com/uncle-bob/2019/06/16/ObjectsAndDataStructures.html
Domain Driven Design Book by Eric Evans: https://dddcommunity.org/book/evans_2003/
Domain Driven Design Quickly book: https://www.infoq.com/minibooks/domain-driven-design-quickly/#minibookDownload, /minibooks/domain-driven-design-quickly/#minibookDownload/
Data structures vs objects by Uncle Bob: https://blog.cleancoder.com/uncle-bob/2019/06/16/ObjectsAndDataStructures.html
10 Myths About Java in 2019: https://developer.okta.com/blog/2019/07/15/java-myths-2019
Which Java SDK Should You Use: https://developer.okta.com/blog/2019/01/16/which-java-sdk