rin51のブックマーク - はてなブックマーク

設計/コードレビューで"常に"心がけるポイント - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatena blog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか高凝集クラスに関してメソッドに関して低結合 ③ユニットテストを書きやすいか合言葉筆者執筆書籍現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。
rin51 2022/01/28
> 「責務！テスト！責務！テスト！」
リンク
ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab
この記事はドメイン駆動設計 Advent Calendarの記事です。今年の9月にログラスというスタートアップに転職しました。ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。入社時の状況なにをしたかテストの話が多い理由実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにしたレイヤーごとのオブジェクトの依存関係を整理レイヤーごとのテスト方針クラス名の重要性参照実装を作成した「責務」と「テスト」の重要性
rin51 2020/12/22
「1クラス1パブリックメソッド」クラスが乱立しそうだけど
リンク
新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かドメイン駆動 + オニオンアーキテクチャ概略以前こちらの記事でアプリケーションアーキテクチャについて書きました。こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。アプリケーションアーキテクチャ全体図とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。何かについて議論をする際は、「それはどの層の責務なの？」という
rin51 2020/02/20
アーキテクチャ

DDD
リンク
1