はてなブックマーク

システムと呼ばれるものは、さまざまな要素の関係が複雑で、要素とその関係が変動し、予測が難しく、とらえにくいものである。 システムと呼ばれるものに取り組む時に、自分が意識している５つの視点を簡単にまとめてみた。 ①文脈で考える ②全体と部分で考える ③関係で考える ④ネットワークで考える ⑤プロセスで考える まとめ ①文脈で考える システムを取り巻く環境や、そのシステムがおかれた状況が、そのシステムのさまざまな特徴を生み出しているという、という捉え方。この環境や状況が、システムが存在し持続する文脈となる。 システムと環境は相互に作用する関係にある。つまり、環境が変わればシステムが変化し、システムが変われば、環境になんらかの変化が生まれる。 システムが人工物の場合、取り巻く環境を構成する要素は、三つに分類できる。 その人工物を作る理由や目的 その人工物を作るために利用可能な資源 その人工物を作

2023年6月13日開催の設計コミュニティイベント「現場から学ぶモデル駆動の設計 第24回」で発表した資料の説明です。 スライドを公開しています。 概要 今年の三月に出版された佐藤大典さんの『エンジニアのためのマネジメント入門』に書かれている知識は、ドメイン駆動設計を実践する時にとても役に立ちます。 (2023-6-15 「深い洞察に向かうリファクタリング」と「戦略的設計」の内容を加筆） この本の内容をチームで習得することでドメイン駆動設計をより効果的に進められます。 『エンジニアのためのマネジメント入門』 『ドメイン駆動設計』に取り組む時に、特に関係するのはこの４つの章の内容です。 『ドメイン駆動設計』 エヴァンス氏の『ドメイン駆動設計』は全体は４部で構成されています。 それぞれの部に書かれた内容と『エンジニアのためのマネジメント入門』の内容がどう関係するかを紹介します。 第１部「ドメイ

エヴァンス氏の『ドメイン駆動設計』の背景にある基本アイデアは何かという私の捉え方のメモ書き。 ドメイン駆動設計にはいろいろな側面がある。また書籍『ドメイン駆動設計』は体系だった設計方法論ではなく、設計の考え方とやり方を経験則として言語化してみた、と捉えている。 その経験則（100%ではないが多くの場合に役に立つ原則）の背景にあるエヴァンス氏の基本的な発想は次の５つに要約できると考えている。 ソフトウェアの複雑さは事業活動の複雑さに起因する 技術的な複雑さもあるが、ソフトウェアが複雑になるのは対象領域の複雑さが主たる理由という考え方。 業務アプリケーションであれば、事業活動の複雑さが業務アプリケーションの複雑さの原因と捉える。 ドメイン駆動設計は、この事業活動の複雑さに起因するソフトウェアの複雑さをうまく扱うための工夫、というのが私の捉え方。 ドメイン駆動設計という設計のアプローチを取り入れ

本日(1月18日)発売された、Software Design誌 2023年2月号の第一特集で「ドメイン駆動設計入門」を書きました。 執筆の意図と記事の概要を簡単にまとめておきます。 Software Design 2023年2月号｜技術評論社 執筆の意図 特集のサブタイトルにある通り「設計力を磨きたい」読者が、ドメイン駆動設計の基礎を知ることで「設計の手法とアイデアの引き出し」を増やすことの役に立てればと思い執筆を引き受けました。 重視したこと 断片的な用語やパターンの解説でなく、ドメイン駆動設計の全体像と要点を伝える 全体像を伝えるための図や表を多めにした（ソースコードの例は少ない） 全体像と要点は、原典である『エリック・エヴァンスのドメイン駆動設計』（以下『ドメイン駆動設計』）の説明を中心にした ドメイン駆動設計の具体例として『ドメイン駆動設計』に出てくる国際海上貨物輸送の具体的な業務

はじめに 良い本です。コードを書く人であればだれでもが気づきと学びがあるでしょう。 特に、コードの規模が大きく長期間にわたってさまざまな関係者が読むことになるプログラムを書く人にはぜひ読んでほしい本です。 gihyo.jp この本から学べるのは、どちらかというと「やり方」よりも「考え方」です。 書き方の具体例というよりは、良いコードを書くための考え方を、著者の知見に基づいて丁寧かつ具体的に説明しています。 別の言い方をすると、とにかくコードの具体例で「やり方」を覚えたい、という人には合わないかもしれません。 コードの具体例もたくさん登場しますが、それは「考え方」を説明するための例であって、コードの書き方のお手本やサンプルを集めた本ではありません。 サンプルコードはKotlinです。内容は、どちらかといえばユーザーインタフェースよりという印象です。しかし、Kotlinを知らなくてもほぼ問題な

はじめてScalaに触れたとき、変数宣言(var)と値宣言（val)を使い分ける言語仕様に、なるほどなあ、と思った。簡単に言えば、変数(var)は再代入できて、値（val)は再代入できない。 プログラミングのスタイルとして、var宣言は命令的なプログラミング、val宣言は宣言的なプログラミングになる。どちらのプログラミングスタイルで書いているかを、varとvalで明示できるわけだ。 Javaだと言語の基本の仕組みはすべてが変数。final宣言をすることで再代入をコンパイルエラーにすることはできる。Javaは、C言語やC++などの命令的なプログラミングの系譜の言語なのですべて変数(variable)というのは、とうぜんの言語仕様だった。 命令的なスタイルから宣言的なスタイルに 命令的なプログラミングでは変数(variable)を使う。宣言的なプログラミングでは値(value)を使う。 再代入

この記事はドメイン駆動設計を取り入れたソフトウェア開発を実際にどのようなやり方で進めているかの事例紹介です。 2021年10月のモデルベースで要件定義をやってみた - connpassで発表した資料の解説です。 設計の効果 良い設計は悪い設計よりも変更が楽で安全です。 ドメイン駆動設計は、そういう良い設計を目指すための設計の考え方とやり方の一つです。 ドメイン駆動設計の特徴は次の２つです。 ソフトウェアで扱うさまざまなロジックとデータをドメインに焦点を合わせて整理して記述する 関連するロジックとデータを一つのクラスにカプセル化する ドメインとはソフトウェアの対象領域です。業務アプリケーションであれば、事業活動がドメインです。この記事では、ドメイン（事業活動）に焦点を合わせたクラス設計の考え方とやり方の基本的な流れを紹介します。 画面やユースケース中心のソフトウェア開発 アプリケーション開発

『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう

設計原則はよい設計をするための指針です。 では、よい設計とはなんでしょうか？ もっとも重要なソフトウェア品質は発展性 ソフトウェアの発展性がビジネス価値を生む 発展性をうみだす７つの設計原則 モジュール化 モジュール化の２つのアプローチ 型によるモジュール化 手続き的なモジュール化 関心の分離 関心の4象限 入出力と計算・判断の分離 業務の関心と実装の詳細の分離 もっとも複雑な関心事（ビジネスロジック）の分離を徹底する カプセル化と抽象化 カプセル化 ビジネスロジックのカプセル化 抽象化 データ抽象 ビジネスロジックとデータ抽象 高凝集と疎結合 凝集度 結合度 隠された結合性の問題 定義の一点性 見た目が同じコード 7つの設計原則の学び方 コードの実装例 ドメインオブジェクト設計のガイドライン 実践ガイドとして使える本 設計の考え方を理解するための本 もっとも重要なソフトウェア品質は発展性

システムと呼ばれるものは、さまざまな要素の関係が複雑で、要素とその関係が変動し、予測が難しく、とらえにくいものである。 システムと呼ばれるものに取り組む時に、自分が意識している５つの視点を簡単にまとめてみた。 ①文脈で考える ②全体と部分で考える ③関係で考える ④ネットワークで考える ⑤プロセスで考える まとめ ①文脈で考える システムを取り巻く環境や、そのシステムがおかれた状況が、そのシステムのさまざまな特徴を生み出しているという、という捉え方。この環境や状況が、システムが存在し持続する文脈となる。 システムと環境は相互に作用する関係にある。つまり、環境が変わればシステムが変化し、システムが変われば、環境になんらかの変化が生まれる。 システムが人工物の場合、取り巻く環境を構成する要素は、三つに分類できる。 その人工物を作る理由や目的 その人工物を作るために利用可能な資源 その人工物を作

ビジネスロジック（ドメインロジック）をどうやってモデリングして、どうやって実装するかの実践例を公開しました。 RDRA 2.0 ハンドブックの図書館システムの実装例 (github) ビジネスロジックのもとになる業務モデルやビジネスルールのモデリングは、 モデルベースの要件定義手法 RDRA2.0 を使っています。 RDRA 2.0 ハンドブック (Kindle Unlimited会員は無償です) 実装技術は、Java/Spring Boot/MyBatis/Thymeleafを使っています。 JIGという設計の可視化ツールを使って、ソースコードからパッケージ関連図やクラスの一覧を自動生成しています。 JIGリポジトリ 利用方法 RDRA 2.0 ハンドブックを入手 リポジトリRDRA 2.0 ハンドブックの図書館システムの実装例をクローン Gradleタスク bootRunを実行(アプリ

ソフトウェア開発の問題点 従来のウォータフォール方式で、フェーズ分けと分業を重視し、手続き的なモジュール構造でソフトウェアを開発するやり方には次の問題があります。 大量のドキュメントの作成に膨大な時間と費用がかかる（工程が多く、必要な人員がふくらむ） フェーズ分けと分業のため、関係者の間の認識合わせが難しい（伝言ゲーム） ちょっとした変更でも、調査・修正・確認に膨大な時間がかかる（変更がやっかいで危険） 一方、アジャイルと呼ばれる開発のやり方は、以下の問題が起きがちです。 ソフトウェアの規模が大きくなると、どこになにが書いてあるか理解ができなくなる 増築・改築の繰り返しが、全体の構造と品質を劣化させる 全体を俯瞰したり構造を確認するための情報がなく、変更の影響がわかりにくい ちょっとした変更でも、調査・修正・確認に膨大な時間がかかる（変更がやっかいで危険） どちらのやり方でも 変更がやっか

ソフトウェアでもっとも重視すべき品質は「発展性」なんだと思う。 機能要求や非機能要求は、時間とともに変化する。その要求の変化に対応してソフトウェアを発展させていける能力、つまり発展性こそがソフトウェアの価値を大きく左右する。 発展性に問題があり変化ができないソフトウェアと、発展性に優れ変化と成長を続けやすいソフトウェアの価値の差ということだ。 発展性の価値 顧客のニーズは変化する。また、市場の競合関係も変化する。そういう事業環境の変化にあわせて、ソフトウェアにも変化を続ける能力が求められている。 また、顧客のニーズや市場環境の変化がゆるやかだとしても、事業活動をすれば組織は経験を通じて学び成長していく。開発チームに限っても、ソフトウェア開発運用の経験を積むことで、開発の考え方とやり方にさまざまな学びと成長がある。そうやって学んだ知識を適切にかつ迅速にソフトウェアに反映できるほど、事業により

昨日、株式会社ディマージシェアさん主催の モダンなSIer開発手法 勉強会 - connpassでお話した内容です。 発表に使った資料 要約 発展性に焦点をあわせる（プロジェクト型からプロダクト型へ転換する） オブジェクト指向ソフトウェア構築の考え方（型によるモジュール化）を基本にする ドメイン駆動設計の考え方（ドメインロジックに焦点を合わせ、コアドメインに集中する）を取り入れる 要件定義・仕様・実装を並行して行う 仕様の記述にプログラミン言語(Java)を使う ソースコードから仕様を可視化する 段階的に継続的に品質を向上させる 補足 ソフトウェア開発の複雑さを多面的に捉える ソフトウェアシステムアーキテクチャ構築の原理（第２版）の枠組みで考えてみる。 ７つの視点（ビューポイント） ４つの観点（パースペクティブ) ７つの視点 合目的性 コンテキスト 機能 情報 構造性 開発 実行性 並行性

オブジェクト指向プログラミングを学ぶ オブジェクト指向プログラミングという言葉は、広い意味で使われている。 オブジェクト指向プログラミングをキーワードにすべての情報をかき集めて理解するというアプローチは現実には無理。 目に付いた重要そうなところを見繕って集めてみても、たぶん混乱するだけ。 この記事では、オブジェクト指向プログラミングのいろいろなアプローチの中で、 クラスを使って独自の「型」を定義するプログラミングスタイル 関連するデータとロジックをまとめて、小さな入れ物に格納する「カプセル化」を重視するプログラミングスタイル を学ぶための参考図書を紹介したい。 型とカプセル化に重点を置く設計スタイルがわかってくると、それとは異なるスタイル、異なる力点を置くアプローチとの違いが具体的にわかるようになってくる。*1 *2 まずは、オブジェクト指向プログラミングの中で、型・クラス・カプセル化に力

ドメイン駆動設計との出会い １０年前に、エヴァンスのドメイン駆動設計を初めて読んだ時は、書いてある内容がほとんど理解できなかった。 あまり、面白いとも思わなかった。 当時は、現場でバグだらけのコードと格闘していた。障害が報告されるたびに、リファクタリング本を参考に、該当個所の長いメソッドや大きなクラスを片端からリファクタリング。その結果、コードがわかりやすくなり、やっかいなバグが単純な修正で解消できてしまうことの効果に驚き、設計の重要性を再認識していた。 それ以前は、UNIXとC言語、OracleとPL/SQLという、オブジェクト指向ではない世界で技術を身に着けてきた。 どちらかというとオブジェクト指向には、ネガティブな印象を持っていた。現場では役に立たんだろうと。 バグとの格闘の中で、リファクタリング（設計改善）の威力を肌で感じ、その考え方とやり方がオブジェクト指向に由来するということを