PoEAA 1章

mtoyoshi @mtoyoshij

範囲外ですが、P32の表にあるように、ロジックが複雑なのにトランザクションスクリプトを採用してしまって、プログラムぐちゃぐちゃー。生産性・品質が落ちる、とか RT @ryamari: パターンを使用しても必ずしも成功するとは限らないのか。ちなみに、失敗事例てどんなんあるんやろか。

ricymst @ricymst

各レイヤの見極め（依存の排除、役割分担）は、全く異なるレイヤを追加することを想像する。たしかに。

ricymst @ricymst

パターンを使用しても必ずしも成功するとは限らないのか。メリット・デメリットををきっちり抑えて実践できるようにする必要があるな。ちなみに、失敗事例てどんなんあるんやろか。

ricymst @ricymst

パターンは、ある事象に対して完全な解決をもたらすように思えたけど、そうではなく、適材適所の使い分けや微調整が必要なんだな。これをできるようになるためには、やっぱり経験かな。ハードルがたかい．．．

ricymst @ricymst

システム構成に重要な変更を行うとパフォーマンスは白紙の状態に戻る。実際の現場ではこのような変更が入ったらちゃんとパフォーマンステストしてるんかな。

ricymst @ricymst

「システムから個々のパーツへとどこまでもブレークダウンできる」「簡単には変更できない決定事項」．．．漠然と捉えていたアーキテクチャという定義がなんとなくみえた。アーキテクチャは何でもやじゃないのね。

mtoyoshi @mtoyoshij

#EAA1 ま、これは半分冗談やけど。そんな所に予防線はっておく人は普通いないとは思いますが。 RT あとSIでも「Oracleで！」って言われても「やっぱ保守費がかかるからMySQLで！」って言ってくるんじゃ、、って深読みする人とか。

mtoyoshi @mtoyoshij

そうそう。MVCでいうとCになる。でもこの本の立場では違う。現にロバストネス分析図でもバウンダリはjspとservletを指す（はず）。敢えて書いておいたのはここがややこしいから。 RT @chipstar_light: #EAA1 ３つに分類するならプレゼンテーションなのか。

mtoyoshi @mtoyoshij

PKG作る人は普通考えると思うよ。あとSIでも「Oracleで！」って言われても「やっぱ保守費がかかるからMySQLで！」って言ってくるんじゃ、、って深読みする人とか。 RT @izumin8080: #EAA1 データベースベンダーを変更出来るのをメリットと感じる人、多いかな？

Takuya Kitamura @chipstar_light

#EAA1 とはいえ、プレゼン-ドメイン-データソースの３つに分類するならプレゼンテーションなのか。

Takuya Kitamura @chipstar_light

#EAA1 画面のボタンをトリガーに始まる処理は必ずしも一つのユースケースではないから、このボタン押下で要求される処理の流れとユースケース（ビジネスロジック？）を上手く繋ぎ合わせるのがServletやActionであり、MVCモデルなどでいうコントローラなのかなって理解してた。

Takuya Kitamura @chipstar_light

#EAA1 でも、ServletやStrutsで言うところのActionはプレゼンテーションロジックかというとそれもしっくりこない

Takuya Kitamura @chipstar_light

ドメインレイヤの大分類をユースケースに紐づけるってのは賛成かな。RT @mtoyoshij: #EAA1 で、「ドメインレイヤ」の一番のフロント部分にユースケースを表すクラスがあって・・・

Takuya Kitamura @chipstar_light

この方法はよく使う。クライアントがRIAになったら？とか、DBがファイルになったらとか。そうすることでレイヤの意味が固まってくるし、依存関係も明確になる　RT @izumin8080: #EAA1 レイヤー化出来ているかは、置き換え可能か想像してみると良いってのは分かりやすい

kyoinn3 @XY_kyo

#EAA1 レイアの意識は一般の開発者（現場）にはあまり意識されてないでしょうね。けど設計者やエンジンの開発者にとって、現在僅かの妥協で将来の大きいな手戻り（もしくは修正すら出来なくなるかも）になるかもしれない。見過ごすのはむずい

Takuya Kitamura @chipstar_light

#EAA1 「レイヤ化アーキテクチャーにおいて最も難しいのは、必要なレイヤと、書くレイヤが行うべき内容を決定すること」っていうのはよくわかる。最近はいった案件でもこれで悩んだ。

Takuya Kitamura @chipstar_light

#EAA1 レイヤ化とそれに伴う依存関係を考える作業は個人的に好きだなー。

huskyhead @huskyhead8080

#EAA1 レイヤー化出来ているかは、置き換え可能か想像してみると良いってのは分かりやすい

huskyhead @huskyhead8080

#EAA1 データベースベンダーを変更出来るのをメリットと感じる人、多いかな？今までそんなに思わなかったけど…

huskyhead @huskyhead8080

#EAA1 三つのシステムの例、凄く共感。システムの使われ方、目的を正しく把握して、最適な手段を選択するには幅広い引き出しが必要になる。アーキテクトのパターンを学んだら、次はそれを実現する技術を広く知らないと。

Takuya Kitamura @chipstar_light

#EAA1 「パターンは常に生焼けであり、常に実際のプロジェクトというオーブンで完成させねばらなない」か。確かに。実ロジックをパターンに近づけるだけでなく、パターンを実ロジックと調和させる必要もある

Takuya Kitamura @chipstar_light

#EAA1 EAでは、非論理的なルールを論理的なシステムとして具現化しなければならないという事を意識する必要がある。これは最近ようやくわかってきた。俺らみたいにPKGを作っていると、全てが論理的でないと違和感を感じてしまうけど、EAではそう単純な世界ではないよな。

huskyhead @huskyhead8080

#EAA1 すべてのシステムが大規模なわけではない ＫＣで言うと基幹系が大規模でオープン系のサブシステム達とか事業部システムが小規模かな？

kyoinn3 @XY_kyo

#EAA1 「ドメインとデータソースはプレゼンテーションに依存してはいけない…」レイアだけではなくて、モジュールの間でも同じようにいえると思うけど、自分がシステムを保守する際、密結合になる傾向がよくあるなぁ…

mtoyoshi @mtoyoshij

・・・とまぁこんな感じで「はじめに」「レイヤ化」については以上となります。基本的には個人的に気になったところをただつぶやいているだけです。特段、疑問点はなかったと思っていますが、やり過ごしているだけかもしれませんので、またみなさんのつぶやきを見て勉強させていただきます！おやすみ。