トランザクションスクリプトとDDD
エヴァンスが2003年に書籍 Domain-Driven Design で紹介してから早17年。 やっと時代が追いつき、近年ではこれまでにないほど DDD が注目を集めている。 注目が高まるとともに、DDD を取り扱う良質な書籍も増え、 私自身も複数の DDD の実践を経て、以前よりも理解は進んできたように思う。 そこで、私の現時点での DDD に対する解釈を、一度ここに書き起こし、残してみようと思う。 (これはあくまで現時点での解釈であり、解釈のアップデートがあれば書き換えるかもしれない。) なお本稿では、ドメインエキスパートや、ユビキタス言語といった、 DDD のプロジェクトへの適用側面には触れず、あくまでプログラミングする際に どのように理解、適用していけばよいかを中心に見ていく。 2011年9月、Spring Framework 3.0.6がリリースされて間もない頃、Spring
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 以前こちらの記事でアプリケーションアーキテクチャについて書きました。 こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。 そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。 結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。 アプリケーションアーキテクチャ全体図 とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。 何かについて議論をする際は、 「それはどの層の責務なの？」 という
![新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/da075520c5346bf5227bf90557a35ccf8b5b07ae/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20181210%2F20181210195849.png)
The Onion Architecture : part 1
Programming with Palermo Jeffrey Palermo, Microsoft MVP, Author, Speaker, Clear Measure Chief Architect, Azure DevOps Expert This is part 1. part 2. part 3. part 4. My feed (rss). I’ve spoken several times about a specific type of architecture I call “Onion Architecture”. I’ve found that it leads to more maintainable applications since it emphasizes separation of concerns throughout the system.
データアクセスのパターンと、ActiveRecord や Eloquant による Repository の実装について - 完全に理解した.com
データアクセスのパターンと、ActiveRecord や Eloquant による Repository の実装について はじめに アプリケーション・アーキテクチャについて議論する中で、最近は DDD の戦術的設計やクリーンアーキテクチャなどがキーワードとして解説されることが多いです。 そんな中、データアクセスの実装については Repository 意外の情報源が少なく、また Repository についても「データアクセス用のクラス」くらいの曖昧な定義で使われているケースも多いと思います。 この記事では、そんなデータアクセスのパターンについて改めて整理し、よく見かける議論の 1 つである「Rails の ActiveRecord や Laravel の Eloquant による Repository の実装」についても考察してみます。 注意事項 内容の正確性について この記事はドメイン駆
設計/コードレビューで"常に"心がけるポイント - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービスレイヤ（ServiceLayer）パターン（PofEAA）