ドメイン駆動設計と開発手法に関するmasuda220のブックマーク (6)

  • 変数(variable)と値(value) - ソフトウェア設計を考える

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

    変数(variable)と値(value) - ソフトウェア設計を考える
  • ソフトウェア開発のやり方の改善

    5. 改善の三つの着眼点 開発者が主体的に ➢ 全体像の認識合わせ ➢ つながりを確かめ整える ➢ 軸を強化し、周辺を広げる コードに責任を持つ ・全体に興味を持つ ・俯瞰図を眺めて、方向と関係を確認する習慣 ・俯瞰図を自分で描いて説明する練習 ・つながりに興味を持つ ・つながりを確認する習慣 ・不要なつながりを取り除く習慣 ・軸を中心に考える習慣 ・広げるまえに軸を強化する習慣 ・広げたら、さらに軸を補強する習慣 この三つに取り組むと、見通しのよい、構造が安定し、変更が楽で安全なソフトウェアを生み出せる CCSR手法は、この改善活動を現場に導入し実践するための手引きとヒント 2020/7/30 5

    ソフトウェア開発のやり方の改善
  • RDRAのダイアグラムの位置付け - 日々常々

    RDRA をやってて思うところ。 RDRAでは多くのダイアグラムが定義されていますが、これらのダイアグラムはきっと成果物(最終的に作るものの中核にあるものをこう呼んでみる)では無いです。多分ハマりどころ。 システムコンテキスト図も業務フロー図もユースケース複合図も、どれもRDRAのエディタとビューアでしかありません。中間成果物、もしくは補足資料的な位置付け。 じゃあ成果物が何かって言うと、各アイコンと関連線。詰まるところ全てのアイコンと関連線を持ったリポジトリそのものが成果物なんだと思います。 ダイアグラムを通してリポジトリを読み書きしている感覚。アイコンを見つけやすい、関連線を引きやすいダイアグラムを使ってアイコンを配置し、アイコン間に関連線を引く。その整合性を確認しやすいダイアグラムを使って、アイコンと関連線を検証する。各ダイアグラムはそのためのものでしか無い。 決して「ダイアグラムを

    RDRAのダイアグラムの位置付け - 日々常々
  • ドメイン駆動設計に15年取り組んでわかったこと 「ビジネスルール・値オブジェクト・型」が3つのキーワード

    株式会社ビープラウドが主催するIT勉強会「BPStudy」。#151となる今回は、設計の代表格であるオブジェクト指向、モデリング、そして設計にフォーカスをあて、LT大会を開催しました。「ドメイン駆動設計に取り組んだ15年でわかったこと 」に登壇したのは、ドメイン駆動設計に15年取り組み続けている増田亨氏。ビジネスルールと値オブジェクトと型という3つのキーワードを軸に、ドメイン駆動設計をソフトウェア開発に落とし込む方法論について語りました。講演資料はこちら ビジネス活動に起因する複雑さに立ち向かうドメイン駆動設計 増田亨氏(以下、増田):よろしくお願いします。私は2006年ぐらいからドメイン駆動設計に実際に取り組んで、15年ぐらいやっているんですけど、今日はそれを私なりにわかったことというか、けっこう最近振り切ってこうやってますよという内容を、みなさんの参考になればと思って少しお話しします。

    ドメイン駆動設計に15年取り組んでわかったこと 「ビジネスルール・値オブジェクト・型」が3つのキーワード
    masuda220
    masuda220 2020/06/11
    BPStudyの勉強会でしゃべった内容を記事にしてもらった。しゃべった言葉がそのままなので、だいぶ冗長だけど、雰囲気は伝わりやすいかも。
  • よりよい開発手法 - ソフトウェア設計を考える

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

    よりよい開発手法 - ソフトウェア設計を考える
    masuda220
    masuda220 2020/06/03
    ソフトウェア仕様の記述にプログラミン言語を使い、ツールを使って図や一覧で可視化する。そうすることで、要件定義・仕様化・実装の継ぎ目をなくすモダンでアジャイルな開発手法への取り組み。
  • ビジネスロジックのモデリングと実装 - ソフトウェア設計を考える

    ビジネスロジック(ドメインロジック)をどうやってモデリングして、どうやって実装するかの実践例を公開しました。 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を実行(アプリ

    ビジネスロジックのモデリングと実装 - ソフトウェア設計を考える
    masuda220
    masuda220 2020/06/01
    ビジネスルールの分析と可視化にモデルベースの要件定義手法 RDRA 2.0を使い、Javaを使ってそのままドメインロジックとして表現した実践例です。
  • 1