TheThingsStackを利用する時に知っておきたい全体の構造的理解
使い慣れない道具や製品を使おうとするとき、詳細よりは、全体の仕組みを知りたくなりますよね。
目に見える道具や製品ですらその状態なので、IT/Web システムはなおさらですね。
今回は、OSS 化され、また無償利用も可能な LoRaWAN ネットワークサーバTheThingsNetwork Community Edition の全体構造について触れてみたいと思います。
1. 登場人物
まず、主に登場してくる概念（エンティティ）を列挙します。
2. 関係性
それぞれの関係性を表すと、下図のようになります。
わかりやすいように、ユーザ（アカウント）単位で表現をしています。
重要なのは、「第一階層（ユーザと直接紐づくエンティティ）」と「アプリケーションの中身」です。
3. 第一階層
ユーザと直接紐づくエンティティは３つあります。「アプリケーション」、「ゲートウェイ」、「組織」です。
それぞれ、複数登録することができます。
4. ゲートウェイ
順番が飛びますが、「ゲートウェイ」の部分を説明します。
ゲートウェイは、設置したLoRaWANゲートウェイを指します。ここに紐づくのが、「コラボレータ」です。
「コラボレータ」には、他ユーザ（のアカウント）、あるいは組織が入ります。コラボレータに登録された人・組織へは、当該ゲートウェイの状態を共有することが可能です。管理権限も細かく設定可能です。
5. 組織
「組織」とは、複数のユーザ（のアカウント）や組織を一括りにしたい場合に使う概念です。ここで定義した「組織」を、自身が管理するゲートウェイやアプリケーションのコラボレータに追加することが可能です。
6. アプリケーション
最後に、少しだけ複雑なのが「アプリケーション」です。
当該アプリケーション全体に適用される「ペイロードフォーマッター」、複数の「エンドデバイス」、複数の「インテグレーション（外部連携）」、「コラボレータ」が紐づきます。そして、各エンドデバイスにも「ペイロードフォーマッター」を紐づけることが可能です。
なぜ、アプリケーション全体の「ペイロードフォーマッター」とエンドデバイス毎の「ペイロードフォーマッター」があるのか？少し不思議に思うかもしれません。
実は、複数登録できるエンドデバイスは、必ずしも同一種類のデバイスである必要はありません。温湿度センサー、距離センサー、GPSセンサーなど、用途に応じて様々なデバイスをアプリケーションに紐づけることが可能です。
この場合には、アプリケーション全体に紐づく「ペイロードフォーマッター」は使わず、デバイス毎に「ペイロードフォーマッター」を紐付けないと、それぞれの payload を正しくデコードできません。
「アプリケーション」をどう使うかはユーザ次第であり、汎用性を持たせた構造になっていると理解できます。