タグ

DDDに関するpipoのブックマーク (6)

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

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

    ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab
  • モデルでドメイン知識を表現するとは何か[DDD] - little hands' lab

    DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 概要 DDDの定義についてEric Evansはなんと言っているのか この記事でドメイン駆動開発の定義は以下のようなものであると書きました。 ドメインの中核となる複雑さと機会に焦点を当てる ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する 明示的にそれらのモデルを表現するソフトウェアを書く 境界付けられたコンテキストの中のユビキタス言語で話す では、ドメインの知識を言語化したモデルは、最終的にコードでどのように表現されるのでしょうか? 不変条件 まず、業務の制約に

    モデルでドメイン知識を表現するとは何か[DDD] - little hands' lab
  • ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab

    DDD連載記事 背景・前提 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのかの記事で、 ネット上の文献で紹介されるアーキテクチャが様々なものとなっているのです。IDDDではヘキサゴナルアーキテクチャというものが掲げられていましたが、それを進化させたオニオンアーキテクチャ、クリーンアーキテクチャなどの有名な亜種が存在します。 これが実装に着手する際に非常に大きな混乱を呼ぶのです。文脈の理解、採用するアーキテクチャの選定に時間を取られることでしょう。 と書きました。こちらに対して、私が「一番とっつきやすい」と考えるアーキテクチャを紹介します。 前提としてですが、完全に個人的な経験に基づく私見になります。 DDDの理論の中で、アーキテクチャに関しては「エリック・エヴァンスのドメイン駆動開発」(以下原典)と実践ドメイン駆動開発(以下IDDD)とでも異なったものが紹介されており、唯一の正解

    ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab
  • ドメイン駆動で開発する ラフスケッチから実装まで

    4. 拙い設計 • コードが重複しまくっている • 条件分岐の密林があちこちにある • どこに何が書いてあるかわからない • 変更した時にどこで何が起きるか推測できない • やっていることは解読できるが、なぜ、そこでそ の処理が必要か意味がわからない • パッケージ名/クラス名/メソッド名/変数名/コメン トが嘘だらけ • でも動いてる 動いていなければ、ろくでもない設計であることは誰でもわかるのに… 4 5. 善い設計 • コードの重複がなくなる • 条件分岐の密林がなくなる • どこに何が書いてあるかわかりやすくなる • 変更した時に影響範囲を限定しやすくなる • 処理の意図がすぐわかる • パッケージ名/クラス名/メソッド名/変数名が わかりやすく正確になる – コメントはむしろノイズ 5 ドメイン駆動設計を実践すると、自然にこうなっていく

    ドメイン駆動で開発する ラフスケッチから実装まで
  • RxJava + Flux (+ Kotlin)によるAndroidアプリ設計 - Qiita

    Introduction Androidにとってアプリ設計は永遠の課題だと思います。 Activityが独特のライフサイクルを持っているのがさらに課題を複雑化します。 設計についてはMVCやMVP、MVVM、Clean-Architecture、DDDなどが最近の主流でしょうか。 上記にあがった設計手法に関しては素晴らしい記事がいくつもあるのでとても参考になると思います。 AndroidではMVCよりMVPの方がいいかもしれない http://konifar.hatenablog.com/entry/2015/04/17/010606 [ Android ] - これからの「設計」の話をしよう https://tech.recruit-mp.co.jp/mobile/android-architecture/ AndroidオールスターズでClean Architectureについて発表し

    RxJava + Flux (+ Kotlin)によるAndroidアプリ設計 - Qiita
  • ドメイン駆動設計について DroidKaigi 2017 で登壇しました。

    長らく Y.A.Mの雑記帳というブログでAndroid技術情報を発信しています。最近はなかなか投稿できなくなってしまいましたが、それも仕事としてAndroidに関われているためです。Androidを触り始めたころはまだ学生だったので時間があったんでしょうね。 はじめて Android に関するエントリを投稿したのは 2009 年 5 月 24 日です。当時はJavaFXを触っていたので、NetbeansでAndroidをやろうとしていたようです。 当時のAndroidのバージョンは1.5、Fragment もなく、Support Library もなく、マルチタッチすらなく、ストアは Google Play ではなく Android Market という名前でした。 ここから2、3年くらいは、仕事Android アプリを開発している人はもっぱらメーカーのプリインアプリを作っている方たち

    ドメイン駆動設計について DroidKaigi 2017 で登壇しました。
  • 1