S_a_k_Uの日記みたいなDB

~サクゥーと呼ばないで~

分析/設計

論理回路とルール

ふと、ルールとかロジックを論理回路で書いたら判りやすい?理解しやすい?とか思ってみる。

未知の領域なOODB

例えば、永続化するためにsaveとかstoreとかwriteってなメソッドを実装しようとするとき。

@IT総合トップ>MONOist>メカ設計>甚さんの設計分析大特訓

Think IT> システム開発> 【伝わる!モデリング】シナリオの図解化 【伝わる!モデリング】シナリオの図解化

メール送信はデータ出力の一つの形態

SVFができること 以前のプロジェクトで、メール送信を印刷パッケージの中で実装して、そのまま開発基盤にも組み込んでるけど、SVFも同じような思想でメール送信できるみたい。 いろいろ考えて、同じように考えてる人がいるってのはなんだかウレシイ。

Webサービスっぽくやってみたが…

PL/SQLのプロダクトの中で、CGI(VB)でExcelファイルを生成してるんで、それに倣ってみる。

文化の違い

昨日読んだ下記の記事で、 Ouobpo > ドメインモデルに対する日米の温度差 http://ameblo.jp/ouobpo/entry-10036477015.html モデリングのパターンとして、 ・Transaction Scriptパターン ・Domain Modelパターン があるとしたとき、実は2つは排他的な関係で…

UとIの続き

Domain Modelという言葉の使い方に自身がないので、Model(Controller+Data)としてみるw EntityはEntityで、またDBでのエンティティと紛らわしいので避けてみるw 今自分でセオリーとしている、現実のU字型アーキテクチャの基本思想(分析レベル?)はこん…

ドメインモデルという言葉の使い方に自信がない

この辺りでひがさんの認識が読める??? ひがやすを blog > [goya]レイヤとモデル http://d.hatena.ne.jp/higayasuo/20050817#1124260949 Ouobpo > ドメインモデルに対する日米の温度差 http://ameblo.jp/ouobpo/entry-10036477015.html マイコミジャーナル…

UとI

あなたとわたしではなくて。

オブジェクトは遠く在りて想うもの?

SQLのJOINは、DIのメカニズムの1つって考えてみたり。

ユーザ 会社 ユーザ 従業員 役割 職責 機能 業務

インターフェース

オブジェクト指向の分析/設計でインターフェースの話がでる。 書いたけど、やっぱやめた。をやめた。

機能外要件の実現

とりあえず、AOPでトランザクションと、今回は例外をキャッチしてのエラーログの記録なんかも実現してみたり。