はじめに

いまどきのシステムエンジニアさんって、複雑なロジック処理はどんな風に設計してるんだろうということが気になりだしたので、とりあえずQiitaユーザーさんの何割くらいが下記に述べておりますシステムエンジニアさんに該当するのかはわからないのですが、とりあえず聞いてみよう。

対象読者

システムエンジニアさん。エンベデッド系やネットワーク・インフラエンジニアもシステムエンジニアさんですが、狭くは業務系システムの設計に携わる方がいいな。

ロジック処理の設計標準化とは

私の個人的な経験をつらつらと述べて、こんな感じなんですけどどうでしょうでは、もしかしたら相手にされないかもしれませんので、わりと先進的と思われた下記のThink ITさんの記事を題材に考えてみてほしいと思っています。

要約

リンク先の記事をじっくり読んでいただくことが望ましいですが、そんな時間というかこの記事のお題にそんなにつきあってられないよという方は下記の要約だけでも読んで参加してください。

ロジック処理のフォーマット：設計書作成CAD「SI Object Browser Designer (OBDZ)」を例に、ロジック処理を記述する標準フォーマットについて解説する。

モジュール化の重要性：ソフトウェアを小さな部品に分割し、独立した形で扱えるようにすることで、メンテナンス容易で共通化できるなどのメリットを説明する。

オブジェクト指向との関係：モジュール化はソフトウェア設計の基本的な大原則であり、オブジェクト指向はそれを実現する1つの手法であることを示す。

ロジック定義の具体例：CADツールで作成したロジック一覧画面やロジック定義画面を用いて、ロジックの基本情報、概要、履歴、インターフェース、アクション、処理内容、メッセージなどを定義する方法を紹介する。

という感じの内容です。SIOBDZなかなかすごそうなツールです。CADとはコンピュータが支援する設計環境のことなので、当然このようなツールをCADと呼ぶことに異論はまったくございません。ただ、昔ハードウェアエンジニアとしてメカCADやECADを使った感覚では、ソフトウエア設計のCADってだいぶイメージが違うなという印象はぬぐえないです。

ロジックの中身の書き方

これは記事本文からの引用になります。

また、処理内容には箇条書きフォーマットを用意しますが、複雑なものは自由記述で記載するしかないこと

ここです。ロジック定義画面というのがあるのですが、えっそうなんだ！？というのが率直な感想です。

実際のところ、Excelとかでやられている現場も恐らくけっこう少なくないと思われる中で、この記事で紹介されている設計活動は、いろいろな設計成果物や帳票、データシートを一つのシステムの中に集約統合していらっしゃるので、かなりすごい！という感じです。もちろん。

しかし、やっぱりそうなのかーという確信めいたものを感じてしまいました。

検討課題

それはDDDでこんな風にアーキテクチャ考えてますよとか、というよりは、賞味、システム化対象の業務の中で、非常にめんどい処理が要求されたとき、みなさんはどんな風にその処理内容を設計されているのかなあというところです。

つまり、いわゆるビジネスロジックとも呼ばれる業務的なロジックそのものをどうやって設計しているかということです。

ビジネスロジックとその他の機能要素、非機能要素をどのように構造化するかということはこの記事の主題ではありません。

おわりに

ぜひ、みなさまのコメントでご紹介をお願いいたします。すごく気長にまっています。この記事の投稿日が１年前になってコメントがらがらであっても、たぶん私はQiitaにいます。その近い将来、こんな古い記事にコメントしても返事つかないよなとか思われるかもしれませんが、たぶんだいじょうです。気長にいろいろやっております。

2023/10/19 追記

@kazuo_reveさんの記事¹　への質問コメントで、「内部仕様」「ビジネスロジックのアルゴリズム記述」という単語の解釈が問題になったので、補足のコメントを返させていただきましたが、本記事にも関係しますのでその内容を転記しておきます。

とりあえず「ビジネスロジック」とはビジネス（仕事・業務）上の作業のルール・手順をソフトウェアに置き換えたものまたは置き換えようとするものとさせてください。
「ビジネスロジックのアルゴリズム記述」とは、ソフトウェアに置き換えられた状態の構造化された手続きの記述のことを意味して使っておりました。
よく想定されるバックエンドのAPIコントローラを例にとりますと、コントローラ内での着信制御と戻り制御と、正味のロジックとの間に境界があるなしはとりあえず問わず、APIコントローラへのリクエストパラメータの仕様とレスポンスパラメータの仕様だけが決まっている状態を「外部仕様」または「要求仕様」（の一部）、正味のロジックの詳細が「内部仕様」という意味です。

　要求：ビジネスロジックの概要（ルール・作業マニュアル）
　要求仕様：ビジネスロジックのインターフェースの取り決め
　内部仕様：ビジネスロジックの実現方法詳細

というイメージが私の中では想起されておりまして、

本記事での「ビジネスロジック」もそのような意味で運用しています。

Qiita USDMに対するひと工夫参照 ↩