カテゴリー
サインイン 新規登録

間違いや改善の指摘

内容の技術的な誤り・誤字脱字やミスのご報告・解説やトピックの追記/改善のご要望は教材をさらに良くしていく上でとても貴重なご意見になります。

少しでも気になった点があれば、ご遠慮なく投稿いただけると幸いです🙏

実際には誤りではなく勘違いであっても、ご報告いただけることで教材のブラッシュアップにつながります。

質問ポリシー①

教材受講者みなさんのスムーズな問題解決のために、心がけていただきたいことがあります。

教材の内容に関する質問を投稿しましょう

教材の内容に関係のない質問や教材とは異なる環境・バージョンで進めている場合のエラーなど、教材に関係しない質問は推奨していないため回答できない場合がございます。

その場合、teratailなどの外部サイトを利用して質問することをおすすめします。教材の誤字脱字や追記・改善の要望は「文章の間違いや改善点の指摘」からお願いします。

0-2

2. なぜTODOアプリ設計を学ぶとよいのか

「設計」を学ぶメリット

設計を行う目的

以下の点が上げられます。

  • 製品の意図が明確になる。
  • 製品の意図を関係者間(ドメインエキスパート、開発者等)で共有できる。
  • 最終的に、製品そのものが改善できる。

一口に設計と言っても設計書には色々なものがあります。

作業量を考えたり、チームで開発したりという工程でも設計は様々。設計に対するものとして、最近ではノーコードツールなどで、「実装」は一瞬でできます。しかし、だからこそ設計が大事と言えます。

あるいは言い方が変わり「ドメイン」を考えることが必要などと言われます。プロダクトバックログなどの要求文書に、必ず5W1H、その中でもWHY = 理由をつけましょう、と言われます。

当然、文書にその要求の背景が描かれていると意図を補完しやすいですし、さらには、企画の背景がわかればもっと良い機能を提案をできる可能性も生まれます。

「要求の意図を明示する」ということそのものは、実装そのものに直接効果があるわけではありません。しかし、コミュニケーションをする上での補完的な役割において、その「理由」をつけることでそれが円滑になるということです。

加えて理由が記述されていることのメリットは、その「意図」の記述が、直接ソースコードや設計にも効果を与えられるということがあります。ソフトウェアの実装としても、コード上に何らかの形で良い効果をもたらすことができるのです。

「意図」がコードに反映されうる設計の方が拡張性が高く、要求の意図というのはその背後にある抽象的な考え方を、具体的に表現するきっかけにもなります。

話を少し展開すると、ドメイン指向設計というものにおいては、この抽象的な考え方をドメインモデルと呼び、そのドメインに精通した存在であるドメインエキスパートと開発者が対話しながらソフトウェアを形作ります。

つまり要求における「意図」と設計における抽象的な考え方、「モデル」には深い関係があり、記述が深まることによって設計そのものが深まると言えます。

「TODOアプリ」を学ぶと良い理由

さて、なにか開発をしたいが、何を作ろう?という悩みは結構あるようです。

エンジニアとしていわゆる「個人開発」をやろうというときにも、アイデアが浮かばなくて手が止まってしまうこともあるでしょう。

あるいはこんなサービスがあったら良いのに、と考えながら、しかしどうすればという障壁で手を止めてしまうことがあるかもしれません。

そんな方に初めての開発には「とりあえず」で構わない、TODOアプリを提案します。

たとえば https://www.freecodecamp.org/ でも学べるJavaScript、Bootstrap、HTMLを使えれば十分です。あるいは人気のPythonのみでも、コマンドライン上からも実行できるものでも十分です。誰にでもとっかかりやすいシンプルなプロジェクトに表現できます。

TODOの詳細をいくつか追加したり、付箋リストのメモのようにリストフォームに保存された詳細を見られるようにもできます。リストの項目を削除したい場合は、削除するなど考えることもできます。

  1. 技術面
  2. ビジネス面

以下、両方の側面から、「TODOアプリ」が効果的である理由を説明します。

技術面

  • CRUD操作が学べます。

    • CRUDはCreate, Read, Update, Deleteのことです。
    • 例えばWebAPIにおけるHTTPメソッドのうちGET、POST、PUT、DELETEという各メソッドは、「CRUD」を満たしていると言えます。
    • 例えばSQLにおける命令のうちSELECT、INSERT、UPDATE、DELETE等も同様、「CRUD」と言えます。
    • つまりそれら、「作成(Create)」「読み出し(Read)」「更新(Update)」「削除(Delete)」という、ごく基本的な操作を用いることで、あらゆるアプリケーションに通じる設計を学ぶことができると言えます。
  • データ構造やテーブル構造を意識できます。

    • TODOの参照、作成、更新、削除(TODO完了) 等などと直結して考えやすくなります。
    • 設計しやすく、作りやすくなります。
    • 結果、達成感を得やすくなります。

ビジネス面

難易度も選びやすく、基礎を確実に学習したうえで更には以下のような機能強化もできます。

  • 入力値のバリデーションを作成できます。
  • TODOタスクのフィルタリングを作成できます。
  • その後フレームワークまましたはライブラリを利用して開発できます。

これまで教材通りにアプリをつくってきた方が、自分のアイディアを形にする方法を学ぶために、親しみやすいTODOアプリを題材に設計を学びます。

参考書籍

実践ドメイン駆動設計 | ヴォーン・ヴァーノン, 高木 正弘 | コンピュータ・IT | Kindleストア | Amazon

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) | エリック・エヴァンス, 今関 剛, 和智 右桂, 牧野 祐子 |本 | 通販 | Amazon

ドメイン駆動設計入門 ボトムアップでわかります! ドメイン駆動設計の基本 | 成瀬 允宣 |本 | 通販 | Amazon