The Challenge

Joe was an excited young chap, keen to tell me all about his new startup idea. He was on a mission to help people communicate better and faster. He enjoyed blogging but wondered about how to get people to blog more frequently in smaller amounts. He was calling it micro-blogging. The big idea was that if you restricted the size of the messages to 140 characters that people would post little and often rather than in big messages.

We asked Joe if he felt that this restriction would encourage people to just post short, pithy statements that didn’t really mean anything. He said “Yolo!” We asked Joe how he was going to make money. He said “Yolo!” We asked Joe what he planned to call the product. He said “Twootr!” We thought it sounded like a cool and original idea, so we decided to help him build his product.

The Goal

In this chapter you will learn about the big picture of putting a software application together. A lot of the previous apps in this book were smaller examples—batch jobs that would run on the command line. Twootr is a server-side Java application, similar to the kind of application that most Java developers write.

In this chapter you’ll have the opportunity to learn about a number of different skills:

• How to take a big picture description and break it down into different architectural concerns

• How to use test doubles to isolate and test interactions from different components within your codebase

• How to think outside-in—to go from requirements through to the core of your application domain

At several places in this chapter we will also talk not only about the final design of the software, but how we got there. There are a few places where we show how certain methods iteratively evolved over the development of the project in response to an expanding list of implemented features. This will give you a feel for how software projects can evolve in reality, rather than simply presenting an idealized final design abstract of its thought process.

Twootr Requirements

The previous applications that you’ve seen in this book are all line-of-business applications that process data and documents. Twootr, on the other hand, is a user-facing application. When we talked to Joe about the requirements for his system, it became apparent that he had refined his ideas a bit. Each micro-blog from a user would be called a twoot and users would have a constant stream of twoots. In order to see what other users were twooting about, you would follow those users.

Joe had brainstormed some different use cases—scenarios in which his users use the service. This is the functionality that we need to get working in order to help Joe achieve his goal of helping people communicate better:

• Users log in to Twootr with a unique user ID and password.

• Each user has a set of other users that they follow.

• Users can send a twoot, and any followers who are logged in should immediately see the twoot.

• When users log in they should see all the twoots from their followers since they last logged in.

• Users should be able to delete twoots. Deleted twoots should no longer be visible to followers.

• Users should be able to log in from a mobile phone or a website.

The first step in explaining how we go about implementing a solution fit for Joe’s needs is to overview and outline the big-picture design choices that we face.

Design Overview

If we pick out the last requirement and consider it first then it strikes us that, in contrast to many of the other systems in this book, we need to build a system that has many computers communicating together in some way. This is because our users may be running the software on different computers—for example, one user may load the Twootr website on their desktop at home and another may run Twootr on a mobile phone. How will these different user interfaces talk to each other?

The most common approach taken by software developers trying to approach this kind of problem is to use the client-server model. In this approach to developing distributed applications we group our computers into two main groups. We have clients who request the use of some kind of service and servers who provide the service in question. So in our case our clients would be something like a website or a mobile phone application that provides a UI through which we can communicate with the Twootr server. The server would process the majority of the business logic and send and receive twoots to different clients. This is shown in Figure 6-1.

Figure 6-1. Client-server model

It was clear from the requirements and talking to Joe that a key part of this system working was the ability to immediately view twoots from users you follow. This means that the user interface would have to have the ability to receive twoots from the server as well as send them. There are, in big-picture terms, two different styles of communication that can be used to achieve this goal: pull-based or push-based.

Pull-Based

In a pull-based communication style the client makes a request to the server and queries it for information. This style of communication is often called a point-to-point style or a request-response style of communication. This is a particularly common communication style, used by most of the web. When you load a website it will make an HTTP request to some server, pulling the page’s data. Pull-based communication styles are useful when the client controls what content to load. For example, if you’re browsing wikipedia you control which pages you’re interested in reading about or seeing next and the content responses are sent back to you. This is shown in Figure 6-2.

Figure 6-2. Pull communications

Push-Based

Another approach is a push-based communication style. This could be referred to as a reactive or event-driven communication approach. In this model, streams of events are emitted by a publisher and many subscribers listen to them. So instead of each communication being 1 to 1, they are 1 to many. This is a really useful model for systems where different components need to talk in terms of ongoing communication patterns of multiple events. For example, if you’re designing a stock market exchange then different companies want to see updated prices, or ticks, constantly rather than having to make a new request every time they want to see a new tick. This is shown in Figure 6-3.

Figure 6-3. Push communications

In the case of Twootr, an event-driven communication style seems most suitable for the application as it mainly consists of ongoing streams of twoots. The events in this model would be the twoots themselves. We could definitely still design the application in terms of a request-response communication style. If we went down this route, however, the client would have to be regularly polling the server and asking with a request saying, “Hey, has anyone twooted since my last request?” In an event-driven style you simply subscribe to your events—i.e., follow another user—and the server pushes the twoots that you’re interested in to the client.

This choice of an event-driven communication style influences the rest of the application design from here on in. When we write code that implements the main class of our application, we’ll be receiving events and sending them. How to receive and send events determines the patterns within our code and also how we write tests for our code.

From Events to Design

Having said that, we’re building a client-server application—this chapter will focus on the server-side component rather than the client component. In “User Interface” you will see how a client can be developed for this codebase, and an example client is implemented in the code samples that go with this book. There are two reasons why we focus on the server-side component. First, this is a book on how to write software in Java, which is extensively used on the server side but not so widely on the client side. Second, the server side is where the business logic lies: the brains of the application. The client side is a very simple codebase that just needs to bind a UI to publishing and subscribing events.

Communication

Having established that we want to send and receive events, a common next step in our design would be to pick some kind of technology to send those messages to or from our client to our server. There are lots of choices in this area, and here are a few routes that we could go down:

• WebSockets are a modern, lightweight communications protocol to provide duplex (two-way) communication of events over a TCP stream. They are often used for event-driven communication between a web browser and a web server and is supported by recent browser releases.

• Hosted cloud-based message queues such as Amazon Simple Queue Service are an increasingly popular choice for broadcasting and receiving events. A message queue is a way of performing inter-process communication by sending messages that can either be received by a single process of a group of processes. The benefit of being a hosted service is that your company doesn’t have to expend effort on ensuring that they are reliably hosted.

• There are many good open source message transports or message queues, such as Aeron, ZeroMQ, and AMPQ implementations. Many of these open source projects avoid vendor lock-in, though they may limit your choice of client to something that can interact with a message queue. For example, they wouldn’t be appropriate if your client is a web browser.

That’s far from an exhaustive list, and as you can see different technologies have different trade-offs and use cases. It might be the case that, for your own program, you pick one of these technologies. At a later date you decide that it’s not the right choice and want to pick another. It might be that you wish to choose different types of communications technologies for different types of connecting clients. Either way, making that decision at the beginning of your project and being forced to live with it forever isn’t a great architectural decision. Later in this chapter we will see how it’s possible to abstract away this architectural choice to avoid a big-mistake-up-front architectural decision.

It’s even possibly the case that you may want to combine different communications approaches; for example, by using different communications approaches for different types of client. Figure 6-4 visualizes using WebSockets to communicate with a website and Android push notifications for your Android mobile app.

Figure 6-4. Different communications approaches

The Hexagonal Architecture

In fact, there’s a name for a more general architectural style here that helps us solve this problem. It’s called the Ports and Adapters or Hexagonal architecture and was originally introduced by Alister Cockburn. The idea, shown in Figure 6-5, is that the core of your application is the business logic that you’re writing, and you want to keep different implementation choices separate from this core logic.

Whenever you have a technology-specific concern that you want to decouple from the core of your business logic, you introduce a port. Events from the outside world arrive at and depart from your business logic core through a port. An adapter is the technology-specific implementation code that plugs into the port. For example, we may have a port for publishing and subscribing to UI events and a WebSocket adapter that talks to a web browser.

Figure 6-5. Hexagonal architecture

There are other components within a system for which you might want to create a port and adapter abstraction. One thing that might be relevant to an expanded Twootr implementation is a notification system. Informing users that they have a lot of twoots they might be interested in logging in and seeing would be a port. You may wish to implement this with an adapter for email or text messages.

Another example port that comes to mind is authentication services. You may wish to start off with an adapter that just stores the usernames and passwords, later replacing it with an OAuth backend or tying it to some other system. In the Twootr implementation that this chapter describes we don’t go so far as to abstract out authentication. This is because our requirements and initial brainstorming session haven’t come up with a good reason why we might want different authentication adapters as of yet.

You might be wondering how you separate what should be a port and what should be part of the core domain. At one extreme you could have hundreds or even thousands of ports in your application and nearly everything could be abstracted out of the core domain. At the other extreme you could have none at all. Where you decide your application should live on this sliding scale is a matter of personal judgment and circumstance: there are no rules.

A good principle to help you decide might be to think of anything that is critical to the business problem that you’re solving as living inside the core of the application and anything that is technology specific or involves communicating with the outside world as living outside the core application. That is the principle that we’ve used in this application. So business logic is part of our core domain, but responsibility for persistence and event-driven communication with the UI are hidden behind ports.

Where to Begin

We could proceed with outlining the design in more and more detail at this stage, designing more elaborate diagrams and deciding what functionality should live in what class. We’ve never found that to be a terribly productive approach to writing software. It tends to result in lots of assumptions and design decisions being pushed down into little boxes in an architecture diagram that turn out to be not so little. Diving straight into coding with no thought to overall design is unlikely to result in the best software, either. Software development needs just enough upfront design to avoid it collapsing into chaos, but architecture without coding enough bits to make it real can quickly become sterile and unrealistic.

In the previous chapter you saw an introduction to TDD—test-driven development—so by now you should be familiar with the fact that it’s a good idea to start writing our project with a test class, TwootrTest. So let’s start with a test that our user can log in: shouldBeAbleToAuthenticateUser(). In this test a user will log in and be correctly authenticated. A skeleton for this method can be seen in Example 6-1.

@Test
public void shouldBeAbleToAuthenticateUser()
{
    // receive logon message for valid user

    // logon method returns new endpoint.

    // assert that endpoint is valid
}

In order to implement the test we need to create a Twootr class and have a way of modeling the login event. As a matter of convention in this module any method that corresponds to an event happening will have the prefix on. So, for example, we’re going to create a method here called onLogon. But what is the signature of this method—what information does it need to take as parameters and what should it reply with?

We’ve already made the architectural decision to separate our UI communications layer with a port. So here we need to make a decision as to how to define the API. We need a way of emitting events to a user—for example, that another user who the user is following has twooted. We also need a way of receiving events from a given user. In Java we can just use a method call to represent the events. So whenever a UI adapter wants to publish an event to Twootr, it will call a method on some object owned by the core of the system. Whenever Twootr wants to publish an event, it will call a method on some object owned by the adapter.

But the goal of ports and adapters is that we decouple the core from a specific adapter implementation. This means we need some way of abstracting over different adapters—an interface. We could have chosen to use an abstract class at this point in time. It would have worked, but interfaces are more flexible because adapter classes can implement more than one interface. Also by using an interface we’re discouraging our future selves from the devilish temptation to add some state into the API. Introducing state in an API is bad because different adapter implementations may want to represent their internal state in a different way, so putting state into the API could result in coupling.

We don’t need to use an interface for the object where user events are published as there will only be a single implementation in the core—we can just use a regular class. You can see what our approach looks like visually in Figure 6-6. Of course we need a name, or indeed a pair of names, in order to represent this API for sending and receiving events. There are lots of choices here; in practice, anything that made it clear that these were APIs for sending and receiving events would do well.

We’ve gone with SenderEndPoint for the class that sends events to the core and ReceiverEndPoint for the interface that receives events from the core. We could in fact flip the sender and receiver designations around to work from the perspective of the user or the adapter. This ordering has the advantage that we’re thinking core first, adapters second.

Figure 6-6. Events to code

Now that we know the route we’re going down we can write the shouldBeAbleToAuthenticateUser() test. This just needs to test that when we log on to the system with a valid username that the user logs on. What does logging on mean here? Well, we want to return a valid SenderEndPoint object, as that is the object returned to the UI in order to represent the user who has just logged on. We then need to add a method to our Twootr class in order to represent the logon event happening and allow the test to compile. The signature of our implementation is shown in Example 6-2. Since TDD encourages us to do the minimal implementation work in order to get a test to pass and then evolve the implementation, we’ll just instantiate the SenderEndPoint object and return it from our method.

SenderEndPoint onLogon(String userId, ReceiverEndPoint receiver);

Now that we’ve got a nice green bar we need to write another test—shouldNotAuthenticateUnknownUser(). This will ensure that we don’t allow a user who we don’t know about to log on to the system. When writing this test, an interesting issue crops up. How do we model the failure scenario here? We don’t want to return a SenderEndPoint here, but we do need a way of indicating to our UI that the logon has failed. One approach would be to use exceptions, which we described in Chapter 3.

Exceptions could work here, but arguably it’s a bit of an abuse of the concept. Failing to logon isn’t really an exceptional scenario—it’s a thing that happens all the time. People typo their username, they typo their passwords, and they can sometimes even go to the wrong website! An alternative, and common, approach would be to return the SenderEndPoint if the logon succeeds, and return null if it fails. This is a flawed approach for several reasons:

• If another developer uses the value without checking that it isn’t null, they get a NullPointerException. These kinds of bugs are incredibly common mistakes for Java developers to make.

• There is no compile-time support in order to help avoid these kind of issues. They crop up at runtime.

• There is no way to tell from looking at the signature of a method whether it is deliberately returning a null value to model failure or whether there’s just a bug in the code.

A better approach that can help here is to use the Optional data type. This was introduced in Java 8 and models values that may be present or absent. It’s a generic type and can be thought of a box where a value may or may not lurk inside—a collection with only one or no values inside. Using Optional as a return type makes it explicit what happens when the method fails to return its value—it returns the empty Optional. We’ll talk about how to create and use the Optional type throughout this chapter. So we now refactor our onLogon method to have the signature in Example 6-3.

Optional<SenderEndPoint> onLogon(String userId, ReceiverEndPoint receiver);

We also need to modify the shouldBeAbleToAuthenticateUser() test in order to ensure that it checks that the Optional value is present. Our next test is shouldNotAuthenticateUserWithWrongPassword() and is shown in Example 6-4. This test ensures that the user who is logging in has the correct password for their logon to work. That means our onLogon() method needs to not only store the names of our users, but also their passwords in a Map.

    @Test
    public void shouldNotAuthenticateUserWithWrongPassword()
    {
        final Optional<SenderEndPoint> endPoint = twootr.onLogon(
            TestData.USER_ID, "bad password", receiverEndPoint);

        assertFalse(endPoint.isPresent());
    }

A simple approach for storing the data in this case would have been to use a Map<String, String>, where the key is the user ID and the value is the password. In reality, though, the concept of a user is important to our domain. We’ve got stories that refer to users and a lot of the system’s functionality is related to users talking to each other. It’s time for a User domain class to be added to our implementation. Our data structure will be modified to a Map<String, User>, where the key is the user’s ID and the value is the User object for the user in question.

A common criticism about TDD is that it discourages the design of software. That it just leads you to write tests and you end up with an anaemic domain model and have to just rewrite your implementation at some point. By an anaemic domain model we mean a model where the domain objects don’t have much business logic and it’s all scattered across different methods in a procedural style. That’s certainly a fair critique of the way that TDD can sometimes be practiced. Spotting the right point in time to add a domain class or make some concept real in code is a subtle thing. If the concept is something that your user stories are always referring to, though, you should really have something in your problem domain representing it.

There are some clear anti-patterns that you can spot, however. For example, if you’ve built different lookup structures with the same key, that you add to at the same time but relate to different values, then you’re missing a domain class. So if we track the set of followers and the password for our user and we have two Map objects from the user ID, one onto followers and one onto a password, then there’s a concept in the problem domain missing. We actually introduced our User class here with only a single value that we cared about—the password—but an understanding of the problem domain tells us that users are important so we weren’t being overly premature.

Passwords and Security

So far we’ve avoid talking about security at all. In fact, not talking about security concerns and hoping that they will just go away is the technology industries’ favorite security strategy. Explaining how to write secure code isn’t a primary, or even secondary, objective of this book; however, Twootr does use and store passwords for authentication so it’s worth thinking a little about this topic.

The simplest approach to storing passwords is to treat them like any other String, known as storing them plain text. This is bad practice in general as it means anyone who has access to your database has access to the passwords of all your users. A malicious person or organization can, and in many cases has, used plain-text passwords in order to log in to your system and pretend to be the users. Additionally, many people use the same password for multiple different services. If you don’t believe us, ask any of your elderly relatives!

In order to avoid anyone with access to your database just reading the passwords, you can apply a cryptographic hash function to the password. This is a function that takes some arbitrarily sized input string and converts it to some output, called a digest. Cryptographic hash functions are deterministic, so that if you want to hash the same input again you can get the same result. This is essential in order to be able to check the hashed password later. Another key property is that while it should be quick to go from input to digest, the reverse function should take so long or use so much memory that it is impractical for an attacker to reverse the digest.

The design of cryptographic hash functions is an active research topic on which governments and companies spend a lot of money. They are hard to implement correctly so you should never write your own—Twootr uses an established Java library called Bouncy Castle. This is open source and has undergone heavy peer review. Twootr uses the Scrypt hashing function, which is a modern algorithm specifically designed for storing passwords. Example 6-5 shows an example of the code.

class KeyGenerator {
    private static final int SCRYPT_COST = 16384;
    private static final int SCRYPT_BLOCK_SIZE = 8;
    private static final int SCRYPT_PARALLELISM = 1;
    private static final int KEY_LENGTH = 20;

    private static final int SALT_LENGTH = 16;

    private static final SecureRandom secureRandom = new SecureRandom();

    static byte[] hash(final String password, final byte[] salt) {
        final byte[] passwordBytes = password.getBytes(UTF_16);
        return SCrypt.generate(
            passwordBytes,
            salt,
            SCRYPT_COST,
            SCRYPT_BLOCK_SIZE,
            SCRYPT_PARALLELISM,
            KEY_LENGTH);
    }

    static byte[] newSalt() {
        final byte[] salt = new byte[SALT_LENGTH];
        secureRandom.nextBytes(salt);
        return salt;
    }
}

A problem that many hashing schemes have is that even though they are very computationally expensive to compute, it may be feasible to compute a reversal of the hashing function through brute forcing all the keys up to a certain length or through a rainbow table. In order to guard against this possibility, we use a salt. Salts are extra randomly generated input that is added to a cryptographic hashing function. By adding some extra input to each password that the user wouldn’t enter, but is randomly generated, we stop someone from being able to create a reverse lookup of the hashing function. They would need to know the hashing function and the salt.

Now we’ve mentioned a few basic security concepts here around the idea of storing passwords. In reality, keeping a system secure is an ongoing effort. Not only do you need to worry about the security of data at rest, but also data in flight. When someone connects to your server from a client, it needs to transmit the user’s password over a network connection. If a malicious attacker intercepts this connection, they could take a copy of the password and use it to do the most dastardly thing possible in 140 characters!

In the case of Twootr, we receive a login message via WebSockets. This means that for our application to be secure the WebSocket connection needs to be secure against a man-in-the-middle attack. There are several ways to do this; the most common and simplest is to use Transport Layer Security (TLS), which is a cryptographic protocol that aims to provide privacy and data integrity to data sent out over its connection.

Organizations with a mature understanding of security build regular reviews and analysis into the design of their software. For example, they might periodically bring in outside consultants or an internal team to attempt to penetrate a system’s security defenses by playing the role of a attacker.

Followers and Twoots

The next requirement that we need to address is following users. You can think about designing software in one of two different ways. One of those approaches, called bottom-up, starts with designing the core of the application—data storage models or relationships between core domain objects—works its way up to building the functionality of the system. A bottom-up way of looking at following between users would be to decide how to model the relationship between users that following entails. It’s clearly a many-to-many relationship since each user can have many followers and a user can follow many other users. You would then proceed to layer on top of this data model the business functionality that is required to keep users happy.

The other approach is a top-down approach to software development. This starts with user requirements or stories and tries to develop the behavior or functionality needed to implement these stories, slowly driving down to the concerns of storage or data modeling. For example, we would start with the API for receiving an event to follow another user and then design whatever storage mechanism is needed for this behavior, slowly working from API to business logic to persistence.

It is hard to say that one approach is better in all circumstances and that the other should always be avoided; however, for the line-of-business type of applications that Java is very popular for writing our experience is that a top-down approach works best. This is because the temptation when you start with data modeling or designing the core domain of your software is that you can expend unncessary time on features that aren’t necessary for your software to work. The downside of a top-down approach is that sometimes as you build out more requirements and stories your initial design can be unsatisfactory. This means that you need to take a vigilant and iterative approach to software design, where you constantly improve it over time.

In this chapter of the book we will show you a top-down approach. This means that we start with a test to prove out the functionality of following users, shown in Example 6-6. In this case our UI will be sending us a event to indicate that a user wants to follow another user, so our test will call the onFollow method of our end point with the unique ID of the user to follow as an argument. Of course, this method doesn’t yet exist—so we need to declare it in the Twootr class in order to get the code to compile.

    @Test
    public void shouldFollowValidUser()
    {
        logon();

        final FollowStatus followStatus = endPoint.onFollow(TestData.OTHER_USER_ID);

        assertEquals(SUCCESS, followStatus);
    }

public enum FollowStatus {
    SUCCESS,
    INVALID_USER,
    ALREADY_FOLLOWING
}

    @Test
    public void shouldNotDuplicateFollowValidUser()
    {
        logon();

        endPoint.onFollow(TestData.OTHER_USER_ID);

        final FollowStatus followStatus = endPoint.onFollow(TestData.OTHER_USER_ID);
        assertEquals(ALREADY_FOLLOWING, followStatus);
    }

public interface ReceiverEndPoint {
    void onTwoot(Twoot twoot);
}

public class MockReceiverEndPoint implements ReceiverEndPoint
{
    private final List<Twoot> receivedTwoots = new ArrayList<>();

    @Override
    public void onTwoot(final Twoot twoot)
    {
        receivedTwoots.add(twoot);
    }

    public void verifyOnTwoot(final Twoot twoot)
    {
        assertThat(
            receivedTwoots,
            contains(twoot));
    }
}

    private final ReceiverEndPoint receiverEndPoint = mock(ReceiverEndPoint.class);

verify(receiverEndPoint).onTwoot(aTwootObject);

public class SenderEndPoint {
    private final User user;
    private final Twootr twootr;

    SenderEndPoint(final User user, final Twootr twootr) {
        Objects.requireNonNull(user, "user");
        Objects.requireNonNull(twootr, "twootr");

        this.user = user;
        this.twootr = twootr;
    }

    public FollowStatus onFollow(final String userIdToFollow) {
        Objects.requireNonNull(userIdToFollow, "userIdToFollow");

        return twootr.onFollow(user, userIdToFollow);
    }

void onSendTwoot(final String id, final User user, final String content)
{
    final String userId = user.getId();
    final Twoot twoot = new Twoot(id, userId, content);
    user.followers()
        .filter(User::isLoggedOn)
        .forEach(follower -> follower.receiveTwoot(twoot));
}

    @Test
    public void shouldReceiveTwootsFromFollowedUser()
    {
        final String id = "1";

        logon();

        endPoint.onFollow(TestData.OTHER_USER_ID);

        final SenderEndPoint otherEndPoint = otherLogon();
        otherEndPoint.onSendTwoot(id, TWOOT);

        verify(twootRepository).add(id, TestData.OTHER_USER_ID, TWOOT);
        verify(receiverEndPoint).onTwoot(new Twoot(id, TestData.OTHER_USER_ID, TWOOT, new Position(0)));
    }

Positions

You will learn about Position objects very soon, but before presenting their definition we should meet their motivation. The next the requirement that we need to get working is that when a user logs in they should see all the twoots from their followers since they last logged in. This entails needing to be able to perform some kind of replay of the different twoots, and know what twoots haven’t been seen when a user logs on. Example 6-16 shows a test of that functionality.

    @Test
    public void shouldReceiveReplayOfTwootsAfterLogoff()
    {
        final String id = "1";

        userFollowsOtherUser();

        final SenderEndPoint otherEndPoint = otherLogon();
        otherEndPoint.onSendTwoot(id, TWOOT);

        logon();

        verify(receiverEndPoint).onTwoot(twootAt(id, POSITION_1));
    }

In order to implement this functionality, our system needs to know what twoots were sent while a user was logged off. There are lots of different ways that we could think about designing this feature. Different approaches may have different trade-offs in terms of implementation complexity, correctness, and performance/scalability. Since we’re just starting out building Twootr and not expecting many users to begin with, focusing on scalability issues isn’t our goal here:

• We could track the time of every twoot and the time that a user logs off and search for twoots between those times.

• We could think of twoots as a contiguous stream where each twoot has a position within the stream and record the position when a user logs off.

• We could use positions and record the position of the last seen twoot.

When considering the different designs we would lean away from ordering messages by time. It’s the kind of decision that feels like a good idea. Let’s suppose we store the time unit in terms of milliseconds—what happens if we receive two twoots within the same time interval? We wouldn’t know the order between those twoots. What if a twoot is received on the same millisecond that a user logs off?

Recording the times at which users log off is another problematic event as well. It might be OK if a user will only ever log off by explicitly clicking a button. In practice, however, that’s only one of several ways in which they can stop using our UI. Perhaps they’ll close the web browser without explicitly logging off, or perhaps their web browser will crash. What happens if they connect from two web browsers and then log off from one of them? What happens if their mobile phone runs out of battery or closes the app?

We decided the safest approach to knowing from where to replay the twoots was to assign positions to twoots and then store the position up to which each user has seen. In order to define positions we introduce a small value object called Position, which is shown in Example 6-17. This class also has a constant value for the initial position where streams will be before the stream starts. Since all of our position values will be positive, we could use any negative integer for the initial position: -1 is chosen here.

public class Position {
    /**
     * Position before any tweets have been seen
     */
    public static final Position INITIAL_POSITION = new Position(-1);

    private final int value;

    public Position(final int value) {
        this.value = value;
    }

    public int getValue() {
        return value;
    }

    @Override
    public String toString() {
        return "Position{" +
            "value=" + value +
            '}';
    }

    @Override
    public boolean equals(final Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;

        final Position position = (Position) o;

        return value == position.value;
    }

    @Override
    public int hashCode() {
        return value;
    }

    public Position next() {
        return new Position(value + 1);
    }
}

This class looks a little bit complex, doesn’t it? At this point in your programming you may ask yourself: Why do I have these equals() and hashCode() methods defined on it, rather than just let Java handle them for me? What is a value object? Why am I asking so many questions? Don’t worry, we have just introduced a new topic and will answer your questions soon. It is often very convenient to introduce small objects that represent values that are compounds of fields or give a relevant domain name to some numeric value. Our Position class is one example; another one might be the Point class that you see in Example 6-18.

class Point {
    private final int x;
    private final int y;

    Point(final int x, final int y) {
        this.x = x;
        this.y = y;
    }

    int getX() {
        return x;
    }

    int getY() {
        return y;
    }

A Point has an x coordinate and a y coordinate, while a Position has just a value. We’ve defined the fields on the class and the getters for those fields.

final Point p1 = new Point(1, 2);
final Point p2 = new Point(1, 2);
System.out.println(p1 == p2); // prints false

    @Override
    public boolean equals(final Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;

        final Point point = (Point) o;

        if (x != point.x) return false;
        return y == point.y;
    }

    @Override
    public int hashCode() {
        int result = x;
        result = 31 * result + y;
        return result;
    }

final Point p1 = new Point(1, 2);
final Point p2 = new Point(1, 2);
System.out.println(p1.equals(p2)); // prints true

Takeaways

• You learned about bigger-picture architectural ideas like communication styles.

• You developed the ability to decouple domain logic from library and framework choices.

• You drove the development of code in this chapter with tests going outside-in.

• You applied object-oriented domain modeling skills to a larger project.

Iterating on You

If you want to extend and solidify the knowledge from this section you could try one of these activities:

• Try the word wrap Kata.

• Without reading the next chapter write down a list of things that need to be implemented in order for Twootr to be complete.

Completing the Challenge

We had a followup meeting with your client Joe and talked about the great progress that was made with the project. A lot of the core domain requirements have been covered and we’ve described how the system could be designed. Of course Twootr isn’t complete at this point. You’ve not heard about how you wire the application up together so that the different components can talk to each other. You’ve also not been exposed to our approach to persist the state of twoots into some kind of storage system that won’t disappear when Twootr is rebooted.

Joe is really excited by both the progress made and he’s really looking forward to seeing the finished Twootr implementation. The final chapter will complete the design of Twootr and cover the remaining topics.