はじめに
日本語プログラミング言語をモデリング言語としてシステム開発上中流工程に導入した場合、そのメリット・デメリットについて考察する記事の5回目です。
本記事の内容はいくつかに分割されて記載されます。本記事中の「本記事」とは分割された内容の総体を指す場合があります。
この記事は日本語構造化仕様記述言語 Re:Mind（リマインド）アドベントカレンダー2023の15日向けの記事です。
対象読者
とりあえずこの記事の想定読者はシステムエンジニアさんです。とくに日本語で要求仕様や内部設計資料を書いている方向けのお話です。
想定しているシステム開発フロー
オーソドックスなリレーショナルデータベースを使用している業務システムであることを1回目2回目の記事で説明しております。
想定しているレイヤードアーキテクチャ・業務
一般的なWebアプリケーションシステムであり、簡単な受発注業務をインターネットで支援するシステムであることを3回目4回目の記事で説明しております。
想定しているユビキタス言語
今回の記事では、その業務システムで使われるユビキタス言語を簡単に例示しておきます。ユビキタス言語とは、本来的な意味ではあらゆる場所にあるコンピュータやネットワークが、人間の自然な言葉で操作できるようになることを指しますが、ここではドメイン駆動設計（DDD）の文脈で用いられる、業務の専門家とシステム開発チームとの共通用語定義の意味で用います。
どちらの意味でも日本語プログラミング言語を知るものにとっては興味深い定義ですが、DDDの世界ではあくまで自然言語の意味だけで認識されることが一般的のようです。
| 単語 | 定義 | 補足・別名など |
|---|---|---|
| 商品 | 価格がつき売り買いの対象となるもの | 価格：貨幣価値 |
| 商取引 | 商品の所有権の移転 | 対価として貨幣が交換される |
| 発注者 | 商取引上の商品の買い手 | 買う：商品を所有し貨幣を引き渡す |
| 受注者 | 商取引上の商品の売り手 | 売る：商品を引き渡し貨幣を受け取る |
| 注文 | 商取引の買い手の意思表示またはその証拠 | |
| 発注 | 商取引の買い手の意思表示 | |
| 受注 | 商取引の売り手の合意表示 | |
| 注文番号 | 数字などからなる注文の識別情報 | |
| 注文日 | 発注者が注文を行った日 | |
| 受注日 | 受注者が注文を承けた日 | |
| 商品コード | 商品の数字などからなる識別情報 | 発注者と受注者で異なるコードをふる場合がある |
| 商品名 | 商品の識別情報で自由文字列 | 受注者が命名する場合が多いがオーダーメード品などは発注者による命名の場合もある |
| 単価 | 商品の販売単位通常１つあたりの価格 | |
| 注文数量 | 特定の注文における商品の数量 | |
| 注文金額 | 注文数量×単価 | 数量や単価に小数点以下の値を含む場合は端数処理の取り決めが必要 |
| 希望納期 | 発注者が受注者に要求する商品の引き渡し期限 | 納期交渉が生じる場合がある |
| 注文書 | 注文の証拠情報 紙の書面または電子データ |
この回のまとめ
ざっくり上流工程の対象業務のユビキタス言語について説明しました。受発注をめぐる電子商取引については、法規制上の問題などさまざまな要件がからんでまいりますが、この記事ではざっくり割愛するとしています。
次回
各工程の詳細について引き続き検討していきます。