It is not just an Integer, it is a Domain Primitive

Dear Junior

Right now I am sitting on train number 928, travelling from home on my way to Arlanda airport and onwards to Explore DDD Conference to present on Domain Primitives together with my friend and colleague Daniel Deogun. Train numer 928 … if I would write a program handling trains I would probably come up with a class named TrainNumber somewhere sooner or later.

Some people might object ”come on Dan, that’s overdoing it, 928 is just an integer” and suggest representing it as a simple int. Me forming a separate class - am I doing it more complex that it is?

For a moment, let us dive into ”it is just an integer”. What does it mean to be ”just an integer” anyway?

Obviously integers are not just a bunch of numbers in a pile. One of the first intellectual things we teach our kids is to count stuff ”one, two, three, four …” pedagogically moving our adult index finger from one toy car to the next. Clearly the fact that ”three” comes immediately after ”four” is something very fundamental for us.

Does that hold for train numbers as well?

Another important property of integers are that we can add them to each other: 4+5=9. This is a really useful property that enable us to take some new-bought apples (five of them) and put them in the fruit bowl where there were some apples since before (four of them). We now know there are nine apples in the bowl. And it neither matters how many apples there were in the bowl, nor how many apples we put in, the result will always be a integer amount of apples.

Of course, integers can be negative. Negatives denote a shortcoming, a lack, or a debt. According to the bank, I own an impressing number of negative Swedish kronor related to my house loan. And when I add Swedish kronor to that negative pile, at time of mortgage, that negative number increase towards zero. Hopefully it will be zero some day.

Does that hold for train numbers as well?

We can also multiply integers: collecting four piles of plates, each six plates high, yields a pile of twenty-four plates. 

Does that hold for train numbers as well?

Zooming out, using mathematical notation: the integers form ”an abelian group under addition”. This means for example that there exists an ”identity element” (denoted 0) such that it doesn’t matter if you add it to another integer: 0+a = a. It also means that for every other element (not 0) there exists an ”inverse” which is the ”opposite”; so as 4 is an integer which is not not 0, there must exist an integer (which we name -4) such that 4 + (-4) = 0.

Does that hold for train numbers as well?

Being ”just an integer” does not seem so simple any longer, doesn’t it? It turns out that integers is a very rich type with a lot of properties (and we have not even started talking about prime numbers yet).

Does really train numbers have all these complex properties?

Of course not: There isn’t necessarily any specific meaning in that train number 928 is ”adjacent to” train number 929. Adding train number 928 and 356 does not necessarily yield a train number. Train numbers are very seldom negativ. Multiplying two train numbers doesn’t  make sense at all (a train-square?). Train numbers does certainly not form an abelian group.

Train numbers are much simper than integers. It’s basically just a set of distinct elements, without any operations or relations apart from comparing two of them.

Train numbers are simply something that is a primitive in our domain. It’s one of the fundamental concepts that the train domain stand on, its parts carry no meaning. In that regard it fulfils the same kind of role that ”language primitives” fulfil in programming languages, but in the train domain. It is a ”train primitive”.

Turing our heads toward programming, think about all the things you can do with an int - just have a look in the Math-class for inspiration. This means that whenever someone think ”train numbers are just integers” they have to take care not to do any of these things that can be done. The TrainNumber class on the other hand can only be used for what it is intended for, nothing else.

Saying that train numbers is a domain primitive, and giving it a class TrainNumber, is not to make things complex. It’s to make things simple.

Yours

   Dan

Impressions from Jfokus 2017: Internet of Things (IoT)

Dear Junior

The annual developer conference Jfokus is always an almost overwhelming source of impressions. There is always lots of interesting presentations, and today was no exception. It's impossible to cover all of them, but today I attended three presentations that together formed a nice whole as they covered different aspects of IoT - Internet of Things.

During the IoT keynote Kevin Hoyt went very down to earth. He covered the state of IoT devices today using different means of connectivity as his starting point. My main take-away was his very thorough coverage of each "typical" device for Bluetooth-, WiFi-, and GSM-connectivity. For each type he demoed the device, showed the development environment, and discussed programming concerns: for example the importance of entering deep sleep when working on a device using Bluetooth and powered by battery. Specifically I took away how the libraries have evolved to make connectivity and features like deep sleep and wake-up-on-connect.

The other presentation that fitted nicely into the topic was the presentation Shahid Raza of RI.SE (Research Institute of Sweden), formerly SICS (Swedish Institute of Computer Science) held under the title "Is IoT Security a Nightmare?". I simply assumed that the question was purely rhetorical, and had expected a "yes" with some elaborations on the subtler points. Boy, was I mistaken. The overarching message of the presentation was a resounding "no". In fact the current protocol stack for IoT has evolved a lot and now even support end-to-end security of communication, even when the data package has to make multi-hops from one device to another before ending up at its final destination. The protocols for doing this are essentially structured in the same way as we do with certificates and HTTPS over TLS. The largest surprise for me was that the computation power needed for cryptographic computation is not a problem. I was under the impression that the power needed for those computations would take too much of a toll from the batteries of battery-powered devices, but apparently not. The largest toll is apparently the radio-transmission of data packages. And, the protocol folks have worked hard to compress the protocol stack so that the overhead-parts of each package (delivery info and security) is compressed so that there is more room for the payload. In that way, fewer packages are needed for the same amount of payload, and that is where you conserve a lot of battery power.

The third presentation was on the just-released Bluetooth 5 standard and was held by Ioannis Glaropoulos. He presented how the new standard has increased throughput of Bluetooth to 2 Mbps, making it feasible for e g streaming audio, which makes the protocol useable for more use-cases. Counter to intuition this might actually decrease battery consumption because the same amount of data can be sent in a shorter amount of time, diminishing the risk of interferences and resending the data. So the amount of energy needed per byte sent might be lower. Bluetooth 5 also features a longer range. For indoor use the main advantage is simpler topologies: many devices can connect directly to a central node or gateway, instead of having to form a mesh where some devices need to route-forward messages from more distant devices. This also conserves energy for the intermediary devices that doesn't need to wake up to forward messages, but can stay in deep sleep until they have something they want to transmit.

Put together these three presentations definitely broadened and deepened my understanding of where Internet of Things stand today. Something that is a worth outcome of a day at a conference.

Yours

   Dan

Writing a book - Secure by Design

Dear Junior

I'm sorry for not writing to you for quite some time. But, you see, I have been working on a book together with my two colleagues and friends Daniel Deogun and Daniel Sawano. Late this summer we decided to try to write down our collective experiences and insights in design and security as a book. We are far from finished, but by now the first few chapters are released from the publisher Manning as part of their "Manning Early Access Program" (MEAP).

The book is named Secure by Design and our main message is how good design and good code can help developers avoid security problems. We have found that lots of security vulnerabilities are due to bugs that could have been avoided if the design of the code had been different. 

You as well as I know that it is a lot easier to think about "good design" when developing features, that it is to think "security" at the same time.

Of course not all good design lead to avoiding security vulnerabilities. So we have gathered our experience on what design-tricks that are most effective in giving security as a side-effect. It's probably no big surprise to you that Domain-Driven Security is an important part of this, but there are many other parts as well.

We still have a lot of material to cover. But, what we have started with things that are close to the code, such as building Domain Primitives, how to structure validation, immutability etc. I guess you will find several of these ideas familiar, as we have discussed them earlier - but there are also some new insights I have not yet had the time to write to you about. Well, not to mention all the ideas from Daniel and Daniel which you and I haven't had possibility to reflect on earlier.

In the later parts there will be more material on integration, security benefits from cloud thinking. We also want to share our ideas around architecture such as security concerns for microservice architecture or how to handle legacy codebases.

We will continue to write during the spring and early summer. Hopefully we will see the book in print sometime during the fall this year.

Yours

   Dan

PS The early-access was released last night; you can check the book at https://www.manning.com/books/secure-by-design