開発手法というのは、過去の経験を元に仮の仕様を考え、それを現実のフィードバックを得ながら、さらに洗練させていくものだと思うので、今回のGoyaへの移行は良いことだと思っています。 シスの復讐による災いが福に転じましたね。 問題は、シス卿です。オ…

くーすは、ユースケースをロバストネス分析して、コントロールの部分をステートレスなロジックに、エンティティの部分を振る舞いを持たないDTOで構成し、ロジックの部分はさらにFDDで分割するというところから、はじまっています。 これが、アーリーくーすで…

今日、DIについて社内でセミナーをやったのですが、CEOも聞きに来るということなので、経営者から見たDIのメリットについても話しました。技術的な話はできないので難しかったのですが、こんな感じ。DIのメリット 特定のフレームワークに依存しない開発が可…

「良くない設計」や「良くない実装」をしてしまわないための一番の近道は、「構造化分析手法」の適用だと考えています。基本的に規模が大きければ大きいほど、携わる人間が多ければ多いほど、そして仕様変更が入る確率が高ければ高いほど、構造化分析および…

Cacheをさわる機会があったので、ODBやモデリングについて考えてみました。結論から言うと ODBを使ったとしても、モデリングやO-ODBマッピングの手法はそれほど変わらない というものです。 ODBを使う場合でも、データが重複しないように正規化は必要です。…

僕の近くにすごく能力があるMDA信者がいるけど，その人曰く「極めて優秀な少人数の人間だけがいればよい日が来る。MDAはそのためのものなのだから」ということらしいですよ。 あからさまにこういわれると反論したくなることでしょう。しかし、抽象的なモデリ…

ロジックをアトミックになるまでばらすという、それは構造化ですね、という方向が見えているのだ 構造化の定義をどうするかによって変わってくると思いますが、トップダウンに段階的に詳細化するのが構造化ということなら、私の考えとは異なります。 DIの世…

ONJava.com: A Look at Commons Chain: The New Java Framework 10:12イマイチありがたさがわかってないCommons Chainの解説記事 この開発スタイルは、実はDIというかくーすを使ったときの開発スタイルとかなり似てます。くーすでは、業務ロジックをアトミッ…

DIは理解するものではなく、体で覚えるものです。使って役に立つからこそ使うのです。 ドキュメントを読んだだけで、まだ良く分からないと思う人がいるなら、まず、自分で幾つか簡単なアプリケーションを作ってみましょう。あるいは、S2JSFの従業員管理のサ…

業務アプリケーションの開発とは、ビジネスモデルをどのように実装するのかということだと思っています。ここでいってるビジネスモデルとは、実際におこなっている業務、あるいはこれからおこなおうとしている業務の形態・仕組みを指すこととします。 という…

>比嘉氏が言いたいのは、ERDは早々に確定するから属性公開しても >影響ないってことだろ。 ということであれば、それでもなお、カプセル化の話は当てはまると思います。カプセル化さえされていればクラスの内部で、Extract Classした先への委譲でも、Replace…

http://d.hatena.ne.jp/higayasuo/20041220#1103529853 >話を簡単にするために常にデータと振る舞いを一緒にするというのは、 >それはそれでOK。 > >ただし、機能が増えるにしたがって役割多すぎなクラスになる >危険性があるということです。最初は、データ…

補足しておくと、ドメインモデルは、もともとデータを持ってるクラスに振る舞いを持たせたほうが良いという観点なはずです。それが、 public class Employee { private PayCaluculator calculator; ... public BigDecimal caluculatePay() { return calculat…

入門 オブジェクト指向設計―変更に強く生産性が高いシステムを http://d.hatena.ne.jp/akon/20041226#p1 くーすシリーズ第1弾 ＃このシリーズ名は私が勝手につけたもので、どこにもオーソライズされてません。 くーすのバックボーンとなった考えがわかりやす…

くーすにおける業務ロジックの設計方法は、実はこれまでほとんど書いてなかったんですね。 心より恥じる(ふるっ) そのため、TransactionScriptだとか構造化手法だとかという誤解が生まれたのでしょう。 くーすにおける業務ロジックの設計手法は、振る舞いの…

リンク先(makotanさん)を読みましたが、データと振る舞いを分けるメリットが よく分かりません。逆にデメリットばかりが思いつきますが。 データ構造を公開することによる疎結合性を妨害 ポリモーフィックな振る舞いを持てない いくつかのデザインパターンの…

http://d.hatena.ne.jp/higayasuo/20041207#1102379088でも書いたのですが、私は、プレゼンテーション層に、ドメインオブジェクトの複雑な構造をみせるのは良くないと思っています。プレゼンテーション層は、プレゼンテーションに徹し、ドメインの知識は持つ…

オブジェクト指向について意見を書くことは、特にデータと振る舞いを1つにすることが、常に正しいとは限らないなんて書くことは、私にとってものすごくリスクの高い&なんのメリットのないことです。 にもかかわらず、あえて書いているのは、正しくオブジェク…

http://d.hatena.ne.jp/makotan/20041219#p4 で、うまくまとめられてると思いますが、できる限りスコープ(役割)を小さく抑えることで、修正が入ったときの影響範囲が小さくなり、保守性が増します。 44氏にコメントするとS2DaoでBeanに関するメタデータは、B…

コメントを受けて 業務アプリケーションをおおくくりに役割分担すると プレゼンテーション層 業務ロジック層(サービス層) データアクセス層 に分割されるのは、別に私がいってるだけでなく、広く世の中に認識されていることではないでしょうか。 データベー…

私の書き方が悪くて誤解を受けた方がいるかもしれませんが、この話は、振る舞いを持たないDTOだとか、状態を持たない業務ロジッククラスの話とは、直接リンクしません。 私がいっているのは、データと振る舞いをカプセル化するという考えは、オブジェクト指…

データと振る舞いを1つにカプセル化する。これは、オブジェクト指向の重要なポイントです。クラスの持つ最も重要な性質だといえるでしょう。 しかし、なんでもかんでもデータと振る舞いを一緒にすれば良いということもありません。 クラス設計の重要な原則で…

くーすにおけるDTOは、(基本的には)エンティティ(ドメインオブジェクト)を継承して、プレゼンテーション層に必要な項目を追加したものです。 正規化されたテーブルを扱いやすいように非正規化するようなものだと考えても良いでしょう。 カプセル化の話で言え…

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?LocalDTO DTOには、主に3つの目的があるように思います。 リモート呼び出しの回数を抑えるための大きなデータの入れ物 オブジェクト間(層間)でデータをやり取りするための入れ物 プレゼンテーション層のモデル 分…

S2JSF EA2で出てくるExampleは、くーすのリファレンスモデルにかなり近くなってます。最も応用が利くだろうと思われるマスターメンテ系の画面構成(検索条件入力、検索結果一覧、編集、確認)になっています。 プレゼンテーション層(Action)、業務ロジック層(L…

DIの本質は、仕様と実装を分離することです。コンポーネントの利用者は、仕様を知っていれば、実装は気にする必要がありません。 このことにより、再利用性、保守性があがります。 仕様と実装の分離は、過去において重要だといわれ続けていたのにもかかわら…

Stateless BusinessLogicにおけるStatelessの意味が分かりづらいところがあるようなので補足します。 ここでいっている「Stateless」とは、 オブジェクトのメソッドを呼び出す前後で、オブジェクトの状態が変わらない。 ということで、「オブジェクトの状態…

http://d.hatena.ne.jp/koichik/20041022#1098468196 を読んで再度整理。 PofEAAでは、リッチなSQLかどうかは関係無いとのこと。 FowlerのいっているTransactionScriptは、(たぶん)従来の手続き型ですね。こういちさんのいっている通り、monolithicなイメー…

ドメインモデルをここでは 業務固有の重要なオブジェクトとそのオブジェクト間の関係をモデル化したもの。 と定義して話を進めます。ドメインオブジェクトは、POJOとして、データアクセスロジックからは切り離されているという前提です。 ドメインモデルは、…

TransactionScriptが、扱うデータを一度に読み込み、ループでまわして、必要なものをセレクト、ということなら、くーすは違います。 最初から、SQLで必要なデータの必要な項目に絞って取得するからです。 Fowlerの言っているリッチなSQLですね。 SQLにロジッ…