タグ

設計とDDDに関するysirmanのブックマーク (10)

  • DDDの実装にはあまり興味がなくなっている - Mitsuyuki.Shiiba

    以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ?って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DBRDBMS)を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから

    DDDの実装にはあまり興味がなくなっている - Mitsuyuki.Shiiba
  • 簡単にできるDDDのモデリング - ドメイン駆動設計 - little hands' lab

    DDDではよく「モデリングが重要だ!」と言われますが、どのようにモデリングすればいいのかがわからず、一歩を踏み出せないことは多いのではないでしょうか。 そんな方のために、記事ではDDDにおいてシンプルで成果が出しやすいモデリング手法について紹介します。 (記事は、YouTube動画「10分でわかるドメインモデリング」の内容をもとにした解説記事です。) DDDの目的 DDDの目的から確認しましょう。 DDDの目的は2つ。 ①機能性を高めること これは、役に立つものを作ること、言い換えると「作ったけど使えない」を避けることです。 そのために、ドメインモデリングを行い、ソフトウェアを適用して役立てようとしている現実世界の領域(これの領域をDDDでは「ドメイン」と呼びます)について理解を深め、解決策を検討することを目指します。 ②保守性を高めること これは、長期間開発しても機能拡張が容易であり

    簡単にできるDDDのモデリング - ドメイン駆動設計 - little hands' lab
  • 「RubyでDDDやるならHanami」という噂の真相

    こんにちは。株式会社InnoScouter CTOの大西(Twitter: @monarisa_masa)です。 InnoScouterでは、Ruby製WebフレームワークであるHanamiを採用しており、DDDを用いて開発しています。 Hanamiについて言うと、私個人としては、前職も含めて4年ほど運用経験があります。 ここでは、Hanamiが出てくるとよく話題にされるRailsとの比較は取り扱いませんが、初めてHanamiについての記事を読まれる方にも分かるようなサンプルコードで説明したいと思います。 突然ですが、こちらが日のメイントピックです。 今回は、「RubyでDDDやるならHanami」と言われてますが、当にそうなの?ってところを掘り下げていきたいと思います。 ツイートが意味していることと、それに対する自分の考えを話していけたらと思います。 この記事の対象読者 Rubyを触

    「RubyでDDDやるならHanami」という噂の真相
  • 設計/コードレビューで"常に"心がけるポイント - little hands' lab

    株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。

    設計/コードレビューで"常に"心がけるポイント - little hands' lab
  • ドメイン駆動設計によるシステム開発 生産ラインのイノベーション

    116 知的資産創造/2020年9月号 I T S O L U T I O N S 題が大きいと考える。現在のシス テム開発生産ラインを簡単に説明 すると、次のようなステップとな る。 ①要求定義や画面・帳票のUI、 ビジネスエンジンなど外部設計 を担当する業務アプリケーショ ンの専門家、基盤・ネットワー クや運用の方式設計するエンジ ニアなどがウォーターフォール モデルの上流工程を担当する。 ②次に、データベース構成・項目 やトランザクションなどを具体 的に設計するアプリケーション エンジニア、基盤・ネットワー IT構築コスト・期間の増加 「システム構築はどうしてこれほ どお金と時間がかかるのだろう」 システム開発にかかわる人は誰し も思っていることである。実際、 大手損害保険会社が第 2 次総合オ ンラインといわれている1980年代 に基幹システムを構築した費用は およそ300億円程度

  • BIGLOBEのエンジニアがDDDをテーマにした登壇動画を公開!組織導入時のポイントとは? - TECH PLAY Magazine

    BIGLOBEで格導入されているDDD 「DDD(ドメイン駆動設計)」を組織に格導入して8年目になるBIGLOBEのエンジニアが社内のノウハウを盛り込んだ登壇動画をアップしました。 動画は以下、BIGLOBE Style(Tech Blog)内の記事から視聴可能です。 BIGLOBE Technology Channel (YouTube) はじめました! 動画の内容は以下7に分かれております。 1. (前編)DDDを始めるなら「成長するドキュメント」から始めよう

    BIGLOBEのエンジニアがDDDをテーマにした登壇動画を公開!組織導入時のポイントとは? - TECH PLAY Magazine
  • CQRSとイベントソーシングの使用法、または「CRUDに何か問題でも?」 | POSTD

    書き込みと読み込みのどちらに力を入れているかは、ストレージエンジンによって異なります。たとえば昔ながらのリレーショナルデータベースは、外部キーなどの制約を使ってデータの整合性をうまく制御できるようになっています。一方でNoSQLデータベースは、スループットとスケーラビリティを確保するために、そういった組み込みのガードレールをはずしてしまいました。データ層においても、どちらか一方に特化した最適化をすることがあります。たとえば、あらかじめ計算済みの値を保持しておけば、「一日あたりのサイト訪問者数」などの読み込み操作を効率よく行えるでしょう。ストレージソリューションのメーカーはどこも、「うちのプロダクトならあらゆるニーズを満たせます」などと自社製品の機能を自慢します。しかし実は、昔ながらのCRUDモデルに沿ってストレージエンジンを選んでデータ層を設計した時点で、さまざまな関心事の間で何らかの妥協

    CQRSとイベントソーシングの使用法、または「CRUDに何か問題でも?」 | POSTD
  • Repositoryパターンのアンチパターン - Qiita

    よく見かけるRepositoryパターンのアンチパターンの紹介と対策です。 Repositoryパターンとは Repositoryパターンとは永続化を隠蔽するためのデザインパターンで、DAO(DataAccessObject)パターンに似ていますが、より高い抽象度でエンティティの操作から永続化ストレージを完全に隠蔽します。 例えばDBコネクションやストレージのパス等はReposiotoryのインターフェースからは隠蔽され、Repositoryのユーザは永続化ストレージが何であるか(例えばMySQLやRedis等)を意識することなく保存や検索の操作を行うことができるようになります。 これによりRepositoryを利用するロジックは業務的な操作に集中できるようになる他、データベースの移行等の永続化層の変更が発生した際にロジックへの影響を切り離すことができるようになります。 // 例) ユーザ

    Repositoryパターンのアンチパターン - Qiita
  • ドメイン駆動設計のカレンダー | Advent Calendar 2020 - Qiita

    The Qiita Advent Calendar 2020 is supported by the following companies, organizations, and services.

    ドメイン駆動設計のカレンダー | Advent Calendar 2020 - Qiita
  • ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab

    この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性

    ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab
  • 1