読者です 読者をやめる 読者になる 読者になる

たなかこういちの開発ノート

システム開発に携わる筆者が、あれこれアウトプットするブログ

DDDと目的-目標-手段に関するポエム^H^H^Hエッセイ

DDD

DDDは、カオスの辺縁を追求するような作業であって、「明らかに誤り」というのはわかっても、「十分に成功した」かどうかは常にわかりにくいのだと思う。 DDDの実践は実際には古くて、自分の観測範囲としては、2000年ごろには、オブジェクト指向の行き着く先…

境界付けられたコンテキストの階層的認識について

要約 境界付けられたコンテキストは、次のように階層的に認識すべきだろう。 (1) 複数のステークホルダー同士が一式の業務用語セットを共有している範囲としてのコンテキスト *一般に複数のサブドメイン横断的である。 (2) (1)のコンテキストと、サブドメイ…

モデル駆動、DSL、自動生成、などについて整理するメモ、その1

モデル駆動の実現方式には、「内部DSL式」か「外部DSL式」かの選択と、「インタープリター式」か「コンパイラー式」かの選択があると考える。 内部DSL 「内部DSL式」では、ホストとなるプログラミング言語と同じレベルでモデル記述する。Javaだったらアノー…

参照系と更新系の非対称性について、追補

以前の記事を補足、あるいは主張を一部修正するものです。 〜・〜 サブジェクト指向とは? ある要求仕様のセットがあったとき、そこに仕様変更のライフサイクルに違いのあるサブセットが認められるならば、それらは、同一のデータ資源(=オブジェクト)に関…

「DDD座談会」に参加してきました

6月5日に開催された、かとじゅん氏(Twitter:@j5ik2o)主催の「DDD座談会」に参加してきました。 後半戦、アルコール後は、文字通りの座談会となり、大いに盛り上がりました。 #dddzk 盛り上がってきたww pic.twitter.com/Ytgj21us5G— なおぴ! (@naopi) 201…

業務プロセス全域をデザインするにおいて、境界付けられたコンテキストを如何に捉えるかという話

要約 エンタープライズ・システムでは、同じ用語でも、部門や担当が異なれば意味も異なっている、という状況は日常的です。各担当が各人のリアルとして見ている個々の"Fact"と、全ての担当の見解を統合的に説明できる“イデア”であり仮説である"Truth"には、…

「OOは静的構造を、関数型は動的振る舞いをモデル化するのに有用だという話」を補足する話、もしくはデータフロー・プログラミングの話

要約 動的振る舞いのモデル化には、単に関数型というよりも、純粋関数型の一つの適用と捉えられる「データフロー・プログラミング」としての理解が有用です。データフロー・プログラミングとは数値計算処理を関数型の概念で再構成したものです。データフロー…

OOは静的構造を、関数型は動的振る舞いをモデル化するのに有用だという話

要約 関心対象について分析し理解しようとしたら、多かれ少なかれ「要素分解していく方法」を取るでしょう。「要素分解していく方法」とは構造を捉えることに関してのアプローチです。 構造を捉えるに当たって、OOは「要素分解していく方法」をよく支援しま…

参照系と更新系の非対称性について

要約 (1) 参照系の要件はもっぱらデータ資源利用側から発せられ、更新系の要件はもっぱらデータ資源提供側から発せられる。 (2) よって、もし「フロントエンド・アプリ」と「バックエンド・サービス」とに階層分けするならば、参照系は「フロントエンド・ア…

P2P取引システムのユースケースの一般構造に関する考察

ビットコインおよびブロックチェーンは、中央の第三者機関が無くとも、相互に信認できる取引を遂行していける仕組みが構築可能な事を示しました。ビットコインやブロックチェーンに触発された「Bitcoin 2.0」などと総称される様々な後続プロジェクトが立ち上…

ウォーターフォールとアジャイルのコスト構造はジレンマ状態にあるのではないか、という話、他

ウォーターフォールかアジャイルか論は、単純にどちらかがより良いとかより悪いとかというよりも、どういう状況のときどういう方法が効果的なのか見極めて、適切に選択していこう、という段階なのだろうと思います。とはいっても、現場的に実際に見極めよう…

ドメインとデータ、サブジェクトとオブジェクト、および、事実は常に事実であり、真実は常に仮説である、という話

先日参加の「PHPメンターズセミナー」には相当に触発されました。本記事はその勢いのままに書いたエントリーとなります。 ※下記記事もご参照ください。 →《PHPメンターズセミナーに参加してきました》 〜・〜 突然ですが、下図は、視点Aから見ると対象物は四…

PHPメンターズセミナーに参加してきました

去る10月3日(土)、「PHPカンファレンス2015」に併設開催の「PHPメンターズセミナー」に参加してきました。 「PHP」関連のカンファレンスではあるのですが、メンターズセミナーの副題は「モデルを設計せよ!-ドメイン駆動設計を超えて」です。しかもツイッ…

書きやすさ重視か、読みやすさ重視か

先日現場のメンバーと、コーディングスタイルについて少々議論したのですが、その結果、プログラミング言語選択やコーディングスタイルには、 - 目下の書きやすさを重視した姿勢 と、 - 後に第三者が読むことを想定した、読みやすさを重視した姿勢 の二つが…

予測型のウォーターフォールに対して適応型のアジャイル

先日、DDD Allianceによる「DDD Alliance! 3週連続DDD 第1週」という勉強会が開催されました。私は参加しなかったのですが、参加者さまによるツイートを眺めていたら「予測型のウォーターフォール、適応型のアジャイル」という趣旨のツイートを目にしました…

「リアクティブ・バックエンドにはScala」、または、プログラミング言語はターゲットとする新プラットフォームの普及とともに普及するものだ、という話

2015年現在、関数型言語が勃興しつつあります。エンタープライズ分野で関数型言語が次世代のプログラミング言語マーケットの覇権を握ることとなるのだとしたら、いつどのように握るのか、それはどの関数型言語なのか、その動向が大いに気になるところです。 …

モデリングとドメインについて

モデルおよびモデリングとは? 「モデル」とは「対象を如何に認識しているかを形式的に描いたもの」と説明できるでしょう。このことを分解していきます。まず、「対象の認識の仕方についての方法論」があるでしょう。どうやって対象を観測するか、観測結果を…

「サブジェクト指向」について(私的実践DDD、その4)(2 of 2)

(※前回からの続きです。) サブジェクトにおいてリポジトリーと集約はいかなる構造を取るか? ここまでで次のような疑問を持たれた方もいらっしゃるでしょう。 『サブジェクトの捉え方は理解したとして、その場合集約やリポジトリーはどのように設計される…

「サブジェクト指向」について(私的実践DDD、その4)(1 of 2)

(※前回からの続きです。) 「サブジェクト指向」の考え方は、オブジェクト指向分析・設計における「関心の分離」に関わる一つの方策として古くから提唱されているものです。人によって多少ニュアンスに違いがありますが、私はおおよそ下記記事が説明すると…

「リアクティブなんとか」はエンタープライズに何をもたらすか?

そもそも「Reactive」とは何か? まずは参考資料をリストします。 InfoQより、「注目を集めるリアクティブプログラミング」: http://www.infoq.com/jp/news/2013/09/reactive-programming-emerging ※オーバービューとして マルレク、2013年1月21日、開催テ…

私的実践DDD、その3

(※前回からの続きです。) 「境界付けられたコンテキスト」は常に理想形を、「サブドメイン」はその時の現実を表す まず確認すると、「リポジトリー」や「集約」はシステムの設計・構築レベルの話でしたが、「境界付けられたコンテキスト」や「サブドメイン…

私的実践DDD、その2

(※前回からの続きです。) CQRSはモデリング上の本質的な課題への対応である CQRS(Command-Query Responsibility Segregation、コマンド・クエリ責務分離)の採用は、現代的なシステムではほぼ全て必然的にそこへ帰結すると考えた方がよいと思います。CQRS…

私的実践DDD、その1

ようやく「実践ドメイン駆動設計」を読み終わりました。 髙木正弘訳、ヴァーン・ヴァーノン著、「実践ドメイン駆動設計」 実際にありそうな開発プロジェクトのストーリーに沿うかたちで話が進められます。コードExampleが極めて具体的に示されて、どうすべき…

キャシュ層を挟む

以前の記事で、フロントエンド-バックエンドのI/Fをどうするか話しましたが、ここにRead Cache層を差し込んでみます。 キャッシュは、最近の大規模サービスではほぼ必須の技術要素といえます。実装としては、memcachedやRedisといったインメモリーKVSがよく…

要件から設計する行為を、「Object」、「Subject」、「Attribute」、「Projection」で説明してみる

(Domain's) Objectとは? 業務プロセスに対する要求・要件の分析観点で抽出される、業務上のひとつの“管理対象”を認識したものを「(Domain's) Object」と、ここでは称することとします。「業務上のひとつの“管理対象”」とは、、業務プロセス内にひとつの部分…

業務プロセス、業務ロジックの理解と、フロントエンド−バックエンド間I/Fの詳細

下記は一般的なn層アーキテクチャーの図です。各層をここでは「Presentation」、「Business Logic」、「Data Access」と表現しています。 ただしいくつか特徴があります。一点目は、参照系と更新系のBusiness Logicを分別して表現していること。二点目は、「…

エラーケースのパターン分類〔ライブラリ実装編〕

(※〔運用編〕からの続きです。) エラーについての一連の記事では「処理」として「業務ロジック」を想定して議論を進めていました。では、その業務ロジックの実行環境・実行基盤たるフレームワークを実装するときや、日付演算ユーティリティ、XMLプロセッサ…

アジャイルでスタートアップも、軌道に乗ったらUPへ移行すべきときが来る、というものかもしれない

前の記事でも書きましたが、この1年ほど、コンシューマー向けWebサービス立ち上げのタイミングで、スクラムを実施する現場に参画することができました。Unified Processベースで開発プロセスを思考していた私にとって、ホンモノのアジャイルの現場は、当初は…

"Issue #19 can't be closed"

歌 アイルちゃん 想いは全てcommitしたわ。 テストコードも抜かりはないの。 お願い、Merge me with u! わたしのプルリク、受け止めて♪ (※現場の某女子によるワンフレーズにインスパイアされて。) ◆ 関連記事 ウー太くんとアイルちゃんの対話 - たなかこう…

ウー太くんとアイルちゃんの対話

ウー太くんは、アイルちゃんに対して次のように問いかけます。 「スケジュールとリソースとスコープについての計画が無ければ一体どうやってプロジェクトをマネージメントすることができるというんだい?」 アイルちゃんはウー太くんに対して、次のように答…

アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話

ここ1年ほど、コンシューマー向けのWebサービス開発のプロジェクトに参画できました。タイミングとしては、フロント側のミニマム版の先行リリースが済んだところから、バックオフィス側を含めた当初予定の機能一式が揃うまで(いわば「Ver.1.0」といったとこ…

扇風機「GreenFan」を生み出したバルミューダ社が、急成長に伴い“アジャイル”から“UP”に転換した話

5月の連休にはいくつか書籍を読みました。そのうちの一冊が次です。 守山久子著/日経デザイン編 、「バルミューダ 奇跡のデザイン経営 ゼロからブランドを築く8つの法則」 バルミューダ株式会社(http://www.balmuda.com/)は、社員数3名、売上4500万円の、…

Web企業とアジャイルの話

一年ほど前の2014年4月に、IPAより「IT人材白書2014」が発行されました。同白書概要版5ページ目をみると、ITに関わる企業群を下記3つに分類しています。 IT企業 ユーザー企業 Web企業 従前よりエンプラ分野に関わっている私からみて、この分類は新鮮に映り…

エラーケースのパターン分類〔運用編〕

(※〔実装編〕からの続きです。) 〔実装編〕にて示した、各Conditionと対応するログレベルの一覧を再掲します。 Condition 終了ケース ログレベル(Log4j) 対応 担当 GREEN 成功終了/肯定的正常終了 INFO − YELLOW 失敗終了/否定的正常終了〔機能要件〕 …

Graph DBでOLTPする方式とGraph DBベースの組織情報管理アプリについて

私は以前の記事で、「Graph DBでは、排他制御の設計が難しいのでOLTPに向かないのではないか?」という見解を書きました。 その後、Amazon Auroraの技術的基礎となっているLog-Structured Storageについて学んだり、その他"Append-Only"方式のDB製品があるこ…

"Append-Only"なRethinkDB、Datomic、CouchDB

以前の記事で、"CRUD is dead"というフレーズについてと、Amazon Aurora同様のLog-Structured Storageを基礎とした「RethinkDB」というDB製品がある(あった)という話を書きました。 その後さらに調べて次のことがわかりました。 ・ まず、"CRUD is dead"と…

Java Day Tokyo 2015に参加してきました

Java Day Tokyo 2015に参加してきました。今年はJava誕生20周年だそうです。下の写真は懇親会で登場したDuke's Birthday Cakeです。 私の職業人人生=業界歴も今年(2015年)で21年目、Javaとほぼ同期だったのです。最初のJavaの仕事は1999年に「Servletは使…

"CRUD is dead"(死んだのは"U"と"D")と「RethinkDB」、もしくはAuroraの周辺話し

ときどき参加させていただいている「Scala勉強会」にて、OE氏(@OE_uia)より、ScalaDays 2015 in San Franciscoのレポートがありました。いろいろ話はあったわけですが、その中でひとつ気になったフレーズがありました。それは、 "CRUD is dead" です。 調べ…

マルレク講義ノート:Amazon Auroraについて

2015年3月24日に開催されたマルレクの講義ノートです。マルレク開催概要と講演資料は下記にて。 マルレク 第六回「Amazonのクラウド・データベースAurora」 開催概要:http://kokucheese.com/s/event/index/271242/ 講演資料:https://drive.google.com/file…

CAP定理とBASEトランザクション(丸山先生の講義より)、そしてMicroservice、最後に「酸と塩基」

もはや3、4年前ですが丸山先生よりCAP定理やBASEトランザクションの講義をうかがう機会がありました。今回改めてまとめてみました。 <参考資料> 丸山不二夫、「Cloudの技術的特徴について」:http://qcontokyo.com/tokyo-2009/pdf/GeneralSession-Day2-Mar…

Graph DBの使い所

結局のところGraph DBはどういった場面によく適用できるのでしょうか?オブジェクト指向の言葉で、 RDBと対比しながら考察してみました。 * RDBの広域構造と局所構造は次のように理解できます。 広域構造の特徴 テーブルはクラスの存在を、テーブルに格納さ…

エラーケースのパターン分類〔実装編〕

(※〔概念編〕からの続きです。) 各Condition=終了ケースをどのよう実装できるか、具体的な(主にJavaによる)実装パターンをまとめました。 Condition 終了ケース Log4j Log Level Java例外 実装例 トランザクション HTTP Status Code (Web API) GREEN 成…

エラーケースのパターン分類〔概念編〕(3/3)

(※前回からの続きです。) ■ 「Condition」の定義 五つの終了ケース類型を改めて下にまとめます。それぞれにイメージカラーを付けています。(※さながらトリアージュの優先度分類風。)筆者はこのカラー表現を「Condition」と称することとしています。 Cond…

エラーケースのパターン分類〔概念編〕(2/3)

(※前回からの続きです。) ■ 「失敗終了」をさらに二つに分類する 「失敗終了」は、その要因に基づいてさらに下記の二つに分類します。 - 機能要件に係るもの - 非機能要件に係るもの 「失敗終了」は、処理呼び出し側が呼び出し時の“契約”を守らなかったこ…

エラーケースのパターン分類〔概念編〕(1/3)

一般にエラーケースあるいは“例外系”などと称される処理の終了ケースを整理し、類型化してみました。なお、ここでいう「処理」とはおおよそ「業務ロジック」のことです。 ■ エラーケースの基礎的な分類 まず、処理(業務ロジック)が、機能要件として期待さ…

フロントエンド・アプリはシナリオとナビゲーションを、バックエンド・サービスはドメインとプロセスを

フロントエンド・アプリ−バックエンド・サービスというアーキテクチャーを採用するとして、具体的に両者の役割分担をどのように線引きすればよいでしょうか。 一つの結論として下記のように考えることができるでしょう。 システムの利用シナリオをよく支援し…

iPhone 6 Plus、所感

iPhone 6+を横に持ってみて想起したのは、HP200LXだ。 HP200LXは、10数行程度のディスプレイサイズを確保し、PC/AT&MS-DOSでできることは全てできる最小サイズだった。あの小ささの中に、デスクトップPC同等の機能性が盛り込まれているという、それが携帯で…

iPhone 6、第一印象

iPhone 6(小さい方)は、素直に「大きくなったね」という印象。 6+(大きい方)の印象は、「でかい」。むしろ「小さいiPad mini」。 6(無印)向けアプリは、従来のiPhone向けのを大きくする、という考えでよいが、6+向けは、iPad向けのを小さくする、と考え…

スマホ向けシステムと企業内SOAは同じアーキテクチャーに収斂する、という話

スマートフォンやタブレット(※以降、単に「スマホ」)の普及に伴って、ひとつのシステムもしくはアプリケーションを、フロントエンドとバックエンドとに切り分けて捉えるアーキテクチャーが一般的になってきました。スマホでは、モバイル端末側にどこまでの…

エンプラ案件において開発物の半分はJavaScriptである、という話

私は「エンタープライズシステムの受託開発」を主な生業にしていますが、最近は、対コンシューマー、対カスタマー用では無く、社内向けの業務管理システムであっても、「リッチクライアントであること」が要件になることが多くなっています。即ち、JavaScrip…