We need a persistence layer on our blog. Authors need to store a blog post in order for a reader to actually read it. Currently we have all functionality in place around creating and updating a blog post, but we don't have any persisitence in place yet. Which makes our blog utterly useless. Until now we pushed the decision for a persistence layer forward, because we wanted to focus on the business logic first. That way we would be in a better position to decide on what technology to use for our persistence layer.

When we started our journey we had the idea that we might be able to use a flat file system or a relational database for our blog. Now that we have most business logic in place we notice that there are some relational relationships emerging in our design. Unfortunately we also have some object oriented concepts in our design that don't really match with a relational database.

Let's investigate and see how best to implement a persistence layer using PostgreSQL as the persistence layer.

In the last few articles we created the functionality for a Blog Author to create blog posts and for a Blog Reader to read the blog posts. The next step is to allow Blog Authors to update existing blog posts. We want to allow multiple authors on the same blog post and of course almost nobody writes the perfect blog post in one go.

The business logic around updating a blog post will be different based on the status of a blog post. For example: we have multiple authors on a single blog post. If someone creates a blog post we link it to the author creating the blog post. When someone updates the blog post, we want that person to be added to the authors list. But only if they do a significant contribution to the blog post. For this article, we will assume that updating a draft blog post is a significant contribution, but when the blog post is already published or scheduled that it is probably just a (spelling) mistake that has been fixed. Which means: updating a draft blog post will add an author. Updating a published or scheduled blog post won't add an author.

Feel free to choose different business logic if it makes sense for you. It really depends on your own requirements how the business logic would look like.

Let's start implementing.

Last article we finalised the implementation of our initial design and requirements. However, the initial requirements weren't complete. How is a reader going to identify a specific blog post? We need some kind of ID. Introducing slugs. A slug is a human readable part of the URL most often related the title of a BlogPost. The slug not only helps with SEO (Search Engine Optimization), but also makes it easier for a user to read the URL and understand where on a website (or Blog) they are.

In the previous articles we made sure that we can create a BlogPost and that we can publish or schedule it. Today we will focus on writing of the blog post itself. In the requirements from part 1 we stated that the blog post author wants to decide on using Markdown or plain HTML to write their post. We expected that there will be requirements for more parsers in the future and we accommodated for that in our design.

As a refresher the UML diagram of our Design below:We introduce a Parser interface which will be responsible for parsing the introduction and content of a BlogPost and provide a parsed result. Every BlogPost will have a reference to its own parser, allowing the Author to decide per BlogPost which parser / technique to use.

In the last article we used Test Driven Development (TDD) to create the constructors of our first three domain models: Category, Author and BlogPost. Today we will focus a bit more on the BlogPost. Based on the requirements in part 1 we came to the conclusion that we have three statuses for a BlogPost: Draft, Scheduled and Published. In this article we will work out the code around these statuses using the State Design Pattern.