Generally, there are 2 ways to have microservices communicate with each other [1]. One technique uses REST to have 1 service directly query or act on another service. The other technique has services pass messages over a message bus. There is plenty of information online about what makes a good REST endpoint, but what makes a good message? There are two ways to think about this question. What does a good message look like? What is a good message about?

A good message doesn’t necessarily need much and is definitely a less is more type of situation. A message needs some identifying information. Who sent it? What’s it about? Some verb? A message also needs a payload. If you separate the what from the content you can then encrypt the message itself without impacting the consumers ability to determine if it’s a message worth paying attention to or not.

What goes in a good message? This is a bit more interesting to me and probably a lot more subjective. I believe this is the true difference between using REST or message passing. In REST one service is asking something of another service, but in message passing one service is telling all the others that something happened. In REST, service A would ask service B for some information, but in message passing service B would send a message letting everyone know about the new state of the world which happens to be consumed by service A.

The downside, and hidden upside, to this is that information will be duplicated. When service B sends an event saying a resource was added and service A consumes that event, service A likely needs some place to store that information. This means duplication of information which is unfortunate. Though a positive is that service A isn’t depending on service B running which increases the stability of your system. Another positive is that service A can store the information in a way that suites it’s needs (I would go so far as to say that it is a bad smell if a resource looks exactly the same in 2 different services).

By keeping all messages in the system informative, instead of action requests, it should be faster to create a system with faster response times. Because all services have centralized the information they need to do what they need, they will not send requests to other services, cutting out extra network time.

What makes a good message? Keep the message itself separate from information about the message. Keep it simple. Stick to messages that inform other services of events that occurred. Avoid messages that ask another service to do something.



Recently, I found myself having some significant issues writing unit tests. I couldn’t quite get the class I was testing into the correct state for some method calls. The class in question, through initializing with request data, was used to determine if a request was authorized or not. At about the time I started googling ways to mock or disable the constructor I realized my issue was that my constructor did too much. This got me thinking, what makes a good constructor?

Wikipedia says that a constructor, “prepares the new object for use, often accepting arguments that the constructor uses to set required member variables.” One of the books on my shelf, which I either learned java from or simply collected over the years, Java Software Solutions by Lewis and Loftus, 3rd edition, says a constructor, “is similar to a method that is invoked when an object is instantiated. … we often use a constructor to initialize the variables associated with each object.” Simula 67, the first language with classes, doesn’t so much have a constructor as allow the programmer to place logic in the class body to be executed. Smalltalk, the first OO language, doesn’t have constructors, though there are conventions. A quote from the first edition of The C++ Programming Language, by Bjarne Stroustrup, may be able to add to this narrative, though I don’t have a copy. Regardless, perhaps history is not be best way to solve this issue.

Thankfully, the quote from the wikipedia article and from Lewis and Loftus, come to an agreement, that a constructor is for setting up object variables. This sounds straightforward enough, but what about my previous example. Is the authorized status of the request a property that should be set by the constructor? Clearly not based on my experience. Perhaps authorized isn’t even a property, but merely an opportunistic caching of a calculation that isn’t going to change, once determined, during the lifetime of the object? I’m inclined to say not; that authorized is a state of the object, which indicates the existence of an object variable to hold said state.

If that is the case, then what states can my object exist in? For my stripped down example, my request object has the states of authorized and unauthorized. Which is where I got into trouble as determining whether a request was authorized required calling a healthy proportion of the object’s methods, and therefore, made it hard to unit test. Do I mock half of the classes methods, nearly all of which are private? find a way to disable the constructor? no is the answer to both of those questions. So I came up with a 3rd state, a base state where I don’t yet know if the request is authorized or not. Now my constructor is nothing but assignment statements and it’s easy to set an object up for unit testing. Unfortunately I’ve had to push logic down into various other functions to handle situations when the information isn’t known and throw appropriate errors.

Woops, turns out that the state of not knowing isn’t a class invariant. Requests aren’t quantum, they actually are either authorized or not. And now I’ve got a problem. Do I make a class that creates objects that always obey their invariants but are not testable, or do I allow what amounts to having 2 methods to fully construct the object but allow it to be fully tested? The later is annoying but the clear winner. An alternate solution I haven’t considered is passing this authorized status to the constructor as an optional parameter or override.

What does the mean for the role of the constructor? It means that the constructor’s role is to set up a state of the object, meaning setting the objects variables, in a way that obeys the class invariants. In a perfect world it would anyway. More practically, it means picking the maximal subset of expert advice and best practices, where maximal is based on the legibility and maintainability of the class. Which is what wikipedia said all along, “prepares the new object for use,” emphasis on prepare.