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

Eric EvansのDDDを読んでます(4)

今回は第6章(ドメインオブジェクトのライフサイクル)まで。

集約

集約はエンティティやバリューオブジェクトを1つのオブジェクトとみなし、扱います。 これにより関連をわかりやすくし、また不変条件を維持することで、オブジェクトの一貫性を保つようにします。

集約は小さなエンティティやバリューオブジェクトだけでは複雑化してしまう関連をシンプルにする役目のようです。また外部からのアクセスを集約のルートになるオブジェクトへのアクセスに制限することで、集約内の不変条件の維持を楽にできるようにしています。

実際のオブジェクト指向プログラミングでも、理解しやすく同時に変更されるような単位にクラスを分離していても、それらにアクセスするのはあるルートになるクラスのみで、他とのやりとりはそのルートになるクラスとしか行わないといったような設計をすることがあるのでイメージはしやすい感じがします。

ファクトリ

ファクトリは集約のインスタンスを生成し、生成されるオブジェクトに複雑な生成の責務を持たせることなく、またクライアントに集約の内部を晒すことがないようにします。

いわゆるGoFデザインパターンの生成に関するパターンに当たるタイプだと考えるとイメージできるかなと思いました。

リポジトリ

リポジトリは永続化されたオブジェクトに対して、メモリ上にあるかのようにアクセスできる方法を提供します。これによりクライアントが実際に内部でどのような永続化技術が使われているかを意識しないで済むようにできます。

またリポジトリで書かれている点で「テストで使用するために、ダミーの実装で置き換えるのが容易になる」というのも書かれていました。

第6章は各パターンはイメージしやすいものが多かったように感じました。 これ以降の章も読み進めつつ、実際の応用について学んでいきたいと思います。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

プログラミングで考えていることについて考察してみる

まえがき

前回までDDDの読書記事書いてたのですが、7章くらいまで読んだあたりで先にやりたいことができてしまったので、一旦中断しています。(6, 7章は年末年始の間に記事書きます)

今回は年末ということで今年の振り返り的な記事を書きます。

続きを読む

Eric EvansのDDDを読んでます(3)

今回は第5章まで。

忙しかったのと、他の本を参照したりしていたので読むペースが少し遅くなってしまっていますが、またペースを戻しつつ進めたいと思います。

あと、ブログのデザインを変えてみました。 もともと大画面で見ている時に幅が狭いかなーと思っていたので、大画面では少し記事の幅が大きくなるように調整しました。

読みやすくなったかな…?

ソフトウェアで表現されたモデル

関連

ドメインを理解することで、関連の方向性と限定された関連を導く。
限定された関連は多重度を減らし、より多くの知識を伝えることができるようになる。

OOPでやっている時に、依存の方向性や関連が複雑にならないように限定するのと似たようなものでしょうか?

このあたり、仕様から実装へ移るときに明示的には意識できていないんじゃないかなと読んでいて思いました。

エンティティ

エンティティは同値性よりも、同一性(identity) によって定義されるオブジェクトである。

こういうときに、"identity"って便利な単語だなと思います。まさに"identity"。

例えば、勤怠管理システムにおけるユーザとかはそれかなと。 同姓同名だったとしても、別の人物であれば別のオブジェクトとして区別されるべきだったりするので。

またエンティティは同一性を保証するための機能が無いといけないため、その保証ができるための操作の設計が必要になる。例えば一意に生成されることが保証されるIDなど。 この同一性の保証に関しては、熟考したほうが良いことが本で示されていました。 例えば、病院をまたいだ医療記録などで、同一性をどう保証するかなど。

奥が深いですね。

値オブジェクト

概念的な同一性がなく、物事の特徴を記述するオブジェクトである。

色とかはそうですかね。

Yellow と 黄色 のどちらを選んでも本質的には変わらないので実際には 「Yellow = 黄色」の図式が成り立つ、みたいな感じですかね。何であるかが重要な問題であって、誰とか、どれとかは意識しなくてよい場合に現れるのが値オブジェクトである、と。

本を読むまでは不変であることが当たり前のようにイメージしていましたが、可変であっても問題ないようですね。 とはいえ、出来る限り不変に設計するほうがよいようですが。。。

サービス

概念的にどのオブジェクトにも属さないような操作を、ドメインに沿った自然な形で表現する。

サービスって、どれをサービスにするかって難しいところじゃないかなーと。 多分、各オブジェクト間でのやりとりで、それを各オブジェクトに持たせるとややこしくなるタイプの操作って感じだとは思うのですが、まだモヤモヤしたところが取り切れていない感じです。

モジュール

モデルにおいて意味のある一部として現れ、より大きな尺度でドメインを表現する。

モジュールを読む際にはマイヤーのOO入門を引っ張り出してきて、少しモジュール性のところを読んだりしていました。 モジュールは低結合・高凝縮であり、内部をよく表現したものである必要があるというのがやはり必要ってことかなという感じでした。ただ、ここにドメインをしっかりと反映するのは大変かなと。

あと、リファクタリングされないモジュールは上記のような低結合・高凝縮で内部をよく表現し、ドメインを反映したものにはできないため、必要ならば再構築などもしっかり行っていくべきだと書かれていました。

モデリングパラダイム

モデル駆動設計では、モデルに対応した実装技術がなければならないということが書かれています。とくにあるとしても成熟していなければ、それを行うことに対してリスクがあるということも書かれています。

最後にパラダイムを混ぜることについても書かれていますが、つかみにくい場所もあったので、次の章を読みつつ更に理解を深められればよいかなと思っています。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

Eric EvansのDDDを読んでます(2)

今回は第4章まで。

第4章の要約

章のタイトルは「ドメインを隔離する」。

レイヤアーキテクチャによってドメインをその他のレイヤと分離する話が書かれています。 また、その対極にあるものとして『利口なUI「アンチパターン」』というものが書かれていました。

レイヤアーキテクチャによるドメインの隔離

DDDではドメイン(レイヤ)をレイヤアーキテクチャにおけるその他のレイヤと分離しておく必要があり、これを達成できていなければ、DDDを行うことができないと書いてあります。

ドメインを中心にして設計を回すのがDDDのはずなので、UIとドメインロジックが一体化していたらドメインロジックの変更が困難だったりするのは大体明らかなところなので、そうかなという感じでした。

後半の章でいかにしてドメインを隔離しておくかということが書かれているらしい。(14、15章)

利口なUI『アンチパターン

一方で、『利口なUI「アンチパターン」』に関しては、「あー、あるあるw」って感じで読みました。いわゆるMVCのModelもViewもControllerも密結合していて、UIの変更も、ドメインロジックの変更もすべてUI・ロジック双方に影響が出るような状況になっているタイプですね。

とりあえず作って終わりなプロトタイププロジェクトのようなものだと全然アリなのですが、何度も何度も繰り返し変更や追加がやってくるようなときには避けたほうがいいパターンだと認識してます(というのは本にも書いてありますね)。

この辺はMVCとかMVVMみたいな考えが役に立ちそうです。

結局のところ、チーム内の知識を高めていかないと、この辺りを避けて通って行くのが辛いというのは本にも書かれていました。チームとして、まずこの『利口なUI「アンチパターン」』が問題なのだという共通認識を作るのは重要なのかなと思いました。

DDDって実際にうまく回すには苦労しそうな点がたくさんありそうですね。「チームでDDDを行うための前提条件になる共通して理解しておくべき事」みたいなものもまとめておいたほうがいいのかもしれないと感じてます。 始めてからでは遅いこと、とか、始めてからでもいいので理解しておいたほうがいいこととか。。。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

Buffetってライブラリを作ってみた

何ヶ月かこそこそと裏で作ってたライブラリを公開しました。

naokirin/Buffet · GitHub

よくあるExcel式データ駆動開発で、ファイルやシートを横断的に検索するのがキツいというのを感じていたので、気軽にデータ定義をするだけでExcelに入っているデータをリレーショナルデータベースで再構築できるといろいろ嬉しいんじゃないかなと思って作りました。

Excelからの読み込みとSQLiteへの流し込み以外の機能が無いので、結構小さめです。

どうってこと無いライブラリなので、すごいものを期待しないでください(GUI部分とかなーんにもないので)。

勉強になったこと。

C# の属性とリフレクション

勉強になったことがいくつかあって、まずはC#の属性とリフレクション。

属性については制限が結構キツイなっていうのをより正確に知ることが出来ました。 使える型が結構限られてて、いくつか妥協して作ってあったりします。

リフレクションに関しては、遅い処理になるためにどうするかみたいなのを色々知ることが出来ました。

Mono

それからMono。

Macで開発していたので、基本はMac上でMonoで動かしてWindowsではあとでちょこっとテストしてみる感じでした。 Monoは.NETで使える機能が使えなかったり、足りなかったり、動かなかったり、etc.
やはりやり始めると色々あるなと実感しました。

ユニットテストは書いてはいますが、バグは結構あると思うので、使ってみようって際にはお気をつけてw

心残りはCode Contracts がMonoでの対応が微妙すぎて、結局使わなかったことですね。。。 使いたかった。。。

SQLite

スマホ向けのアプリ開発でクライアントにデータをもたせるのに使えるんじゃないかってことでSQLiteに目をつけていたのですが、それの前準備としてこのライブラリを作ってみたというのが本音です。

SQLite自体、あまり大きくないデータに対してで言えば、SQLRDBとしては申し分ないのではないかというのが今回触った感想でした。(SQLiteで手にあまるようなExcelデータはもとから間違っているようなものなので…)

ちなみにスマホアプリでC#な理由は、Xamarinだからです、はい。

全体的な感想

とりあえず作ってみようということで作ったところが大きくて、すぐに使える何か、と言うものにはなっていないですが、クラス書けばあとは10行未満でExcelからSQLiteに流し込めるっていうのは悪くないんじゃないかと思っています。

必要があれば、もう少し手を加えていこうかなと思っていますが、一段落はしたかなと思っています。

GUIツールにまで出来るようにしておくのがベストですが、一旦はここまでにしておきます。

Eric EvansのDDDを読んでます(1)

最近、アウトプットが疎かになりつつある感じがしていたので、読書記録でもつけていこうと思います。

最近読み始めた本がEric Evansのドメイン駆動設計(DDD)ですので、こちらの読んでいて感じたこととかを書いていきます。

ちなみに、ちょうどアジャイルソフトウェア開発の奥義を読み終わって、Rebecca Wirfs-Brockのオブジェクトデザインを読み進めたいなと思っていたのですが、最初の方を読んでいてDDDとの密接な関係がある気がしてきて、結局DDDを先に読むことにした感じです。

DDDに関しては、「どう実践するんだ!?」っていうので、イメージが湧いてないところが多い状況のなか読み始めました。

第1章から第3章まで読んだ感想

おぼろげながら具体的な流れが見えてきた感じがします。 第1章から第3章辺りは、結構具体的に例示しながら、DDDをどのように進めるかの概略が示されている感じです。

DDDでは「ドメイン・モデル・設計・実際のコード」という4つをいかにして繋ぐかというのが主題にあるように感じました。 これらのどこか1つでも乖離すると、ドメインと実際のコードがかけ離れていき、結果としては正しくユーザやドメインエキスパートの関心事をシステムに反映できなくなってしまうので、DDDによりこれらを適切につなぎましょうということかなと。

ざっくりこんな感じのことなんだろうと受け取りました。

細かい部分としてはユビキタス言語などもありましたが、なんとなくDDDの目指しているものが見えてきたので、さらに読み進めていこうと思います。

実際の業務でも、この辺りって大事かなと思うところもちらほらあったりするので、この本を読んで何らか生かせればいいなと思ってます。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

アジャイルソフトウェア開発の奥義を読み終えた

苦節2年、ついに読み終えました。

買ってから半年寝かせ、そこから1年半書けてようやく読み終えました。

とは言っても、結局まだまだ実際のコーディングやらに結び付けられているというのは結構少ない感じがしています。 それとだらだらと読んだせいで、細かいところを忘れてたり、時間があったら軽く読み返す必要はあるんじゃないかなと。

内容的には、設計の悪臭とオブジェクト指向設計の原則は、自分の中ではオブジェクト指向に対して一歩前進できたきっかけにはなってるんじゃないかなと思っています。GoFデザインパターンが意識せずともコードの中に出てくる瞬間をよくよく思い返してみると、OCPやらDIPに則った設計をしようとした結果だったりして、デザインパターンをつぶさに覚えていくよりもずっとデザインパターンを深く理解できた気がします。

もちろん、オブジェクト指向の難しさみたいな部分もすごく感じた1冊でした。これだけ深く考え、ようやくこのレベルの設計に到れるんだなと。オブジェクト指向は人類には早かったんや!(笑)

デザインパターンは知っているけど、アジャイルソフトウェア開発の奥義は読んだこと無いみたいな人には特におすすめしたい1冊です。(原則とデザインパターンの関係についてで言うと、石井さんによる記事- Open-Closed Principle とデザインパターンがすごく簡潔で私の理解を進めてくれました。)

なんとか読み終えたという感じですが、読んでいって感じたこととして、設計についての知識を一層深める必要がありそうということでした。次に読み進める本として、たとえば、Eric EvansのDDDやRebecca Wirfs-Brockのオブジェクトデザイン、あとDCIについてLean Architectureなんかを読み進めていきたいかなと思います。(全部積んであったんですけどねw)

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技