Goで書くClean Architecture API - Qiita
Enterprise Business Rules ビジネスルールの為のデータ構造を持ったオブジェクト。 データの実態を表す場所。 Application Business Rules ビジネスルールを操作する場所。 つまりこのアプリケーションで何ができるかを実践します。 Interface Adapter 外部からの入力、データの永続化、表示を担当する場所 Frameworks & Drivers Webフレームワーク、DB操作の実際に担うソース、 フロントエンドのUIなどがここに所属しています。 外側のレイヤーの要素を直接参照してはならない 上記の図におけるこの矢印は依存を表しており、 内側のレイヤーから外側のレイヤーの要素への依存を禁じます。 ここでいう依存とは要素(構造体、変数など)への直接参照をさせないということです。 では外側のレイヤー要素を参照せざる得ないは、どうするのでしょ
ドメインオブジェクトの責務について - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 設計するとき、「このオブジェクトの責務は何だろうか？」とか「この責務に名前をつけるなら何か？」とか、責務について考えることがよくあります。そもそもその責務とは何か、という根源的な疑問について再確認すると共に、ドメイン駆動設計の観点からドメインオブジェクトの責務についても考えてみたいと思います。 責務とは 困ったときの古典引用。もう絶版になった、オブジェクトデザインという、書籍を紐解いてみましょう。DDDからの引用が多い書籍で、DDDの設計スタイルは、この書籍で紹介する「責務駆動設計(responsibillity-driven desi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
