1. Wie können wir Daten/Updates sicher bzw. transaktional zwischen den Services übergeben?
2. Wie schaffen wir es, dass die unterschiedlichen Services nicht auseinanderlaufen?

Das Outbound-Pattern kann uns hierbei helfen, dieses Problem zu lösen. Es handelt sich um eine bewährte Methode, um Datenkonsistenz und Transaktionen in verteilten Systemen zu gewährleisten.

The module pattern is one of the most known and used. It helps us to create private variables or better to avoid side effects in a larger JS application between the different JS files we load or frameworks we use.

The problem

Overall the problem is that in JavaScript everything is more or less public. Currently, most frameworks register their name in the Global space, also known as the window Object. You know them as angular or just $ or maybe even as Y.

Imagine the following code (jsBin):

// first JS file
var CLASS_NAME = "A1";
function A1() {}
A1.prototype.sayHallo = function() {
  $('#out').html(CLASS_NAME + ": says hallo!");
};

// second class in a different JS file
var CLASS_NAME = "B1";
function B1() {}
B1.prototype.sayHallo = function() {
  $('#out').html(CLASS_NAME + ": says hallo!");
};

// some code
$('#cmdA1').click(function() {
  new A1().sayHallo();
});
$('#cmdB1').click(function() {
  new B1().sayHallo();
});

It doesn’t matter which button you press the result will always be B1 because we have overwritten the value in CLASS_NAME in the second part.

Even if this sample is somehow of course constructed, this problem can easily happen in a larger JS application. We must take this into account an protect ourself.

The solution

The solution is pretty straight forward. We just wrap our class definition into an anonymous function. This does not only protect us but it allows us to create really private variables in JS which can’t be overwritten from outside — we can protect the access to them with functions.

jsBin again

// first JS file
MyGlobal = {};
(function($) {
  var CLASS_NAME = "A1";
  function A1() {}
  A1.prototype.sayHallo = function() {
    $('#out').html(CLASS_NAME + ": says hallo!");
  };
  MyGlobal.A1 = A1;
})(window.$); // pass any global scope

// second class in a different JS file
(function($) {
  var CLASS_NAME = "B1";
  function B1() {}
  B1.prototype.sayHallo = function() {
    $('#out').html(CLASS_NAME + ": says hallo!");
  };
  MyGlobal.B1 = B1;
})(window.$);

// some code
$('#cmdA1').click(function() {
  new MyGlobal.A1().sayHallo();
});
$('#cmdB1').click(function() {
  new MyGlobal.B1().sayHallo();
});

What have we learned?

• In JavaScript, the best practice is to wrap our code into anonymous functions
• Define one global scope variable which we use to register all our classes (here MyGlobal)
• Anonymous function also allow us to create private/ protected variables

What is it?

Strong IDs are simply wrapped primitive or simple types into classes. Just remember what we did in Java before the Enum come around. We had just Strings or Numbers in the code which we used to assign well known values to specific objects. In some projects these Strings has already been wrapped into classes. Now with Enums this is mostly obsolete. But for Ids we can still apply this pattern.

Imagine the following classes:

class Office {
  String id;
  String name;
}

class Person {
  String id;
  String name;
}
// we could use any string we want, even the ID from the office
interface PersonService {
  Person getById(String id);
}

Both classes have an id, simply just as a String. Keeping just these ids in hand you cannot tell if it is a Person Id or the Office Id. To make it more obvious we could change the code too:

final class OfficeId {
  String value;
}
class Office {
  OfficeId id;
  String name;
}

final class PersonId {
  String value;
}
class Person {
  PersonId id;
  String name;
}
// we can now use the real type, compile time save
interface PersonService {
   Person getById(PersonId id);
}

If you now have either the OfficeId or PersonId in hand, you cannot accidentally mix them up. You exactly know what you have and what it identifies.

Usually the ID classes are not mutable too.

Advantages

In larger projects you have many classes, it is easier to understand and keep different IDs in method signatures. That we use the right type in generic lists or method calls can be ensured now during compile time.

Also nice we can easyer change the type of ID, e.g. from String to Long or to a composite type.

If we move this sample to REST where we usually want to return a URI as an identifier to an object this pattern even gets more attractive. If we assume our IDs have been initially just simple Longs wrapped into a Strong ID we could change the value it a String and create URI / String which we return to the clients.

Disadvantages

Well no pro without a contra. Having strong ids in the system makes the handling sometimes awkward. E.g. if you serialize this to JSON you get:

// with strong ID
{ id: {value: "abc"}, name: "Main Office"}

// without strong id, or what you usually want
{ id: "abc", name: "Main Office"}

Furthermore Hibernate nor simple bean serializer/ deserializer can handle well immutable classes. Overall we would need to add additional code to handle that. e.g. Hibernate custom types etc.

Github JPA example