iOS Clean Architecture の説明と、実際にMoneyForwardでiOS Clean Architectureを導入してみた話をします。 Sample code: https://github.com/koutalou/ios-cleanarchitecture
![iOS Clean Architecture のすすめ](https://cdn-ak-scissors.b.st-hatena.com/image/square/502f2f3885776e5b24cf13de6d2d9fe4a9aa7e35/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F4c4475c672eb43b8884d0fb3185f74e7%2Fslide_0.jpg%3F7211022)
iOS Clean Architecture の説明と、実際にMoneyForwardでiOS Clean Architectureを導入してみた話をします。 Sample code: https://github.com/koutalou/ios-cleanarchitecture
CureApp では DDD と JavaScript を使って小さなチームで柔軟にマルチプラットフォーム対応を実現しています。ここではそのために実施している方法や必要となる知識を共有します。 ちなみに実際に対応しているプラットフォームは次になります。 Web desktop iOS Android DDD という考え方 DDD とは Domain Driven Design の略で、 Eric Evans がソフトウェア開発を実践する中で得た知識・方法論をまとめて提唱したものです。日本語訳された本が出版されています。 以下これを DDD 本と呼びます。 ドメイン ひとことでいうと「解決したい問題」のことです。ある疾患を治療したいという問題や、もっと簡単に飲料缶を自動販売したいといった問題、つまり自動販売機をどう実現するかなどがあたります。 モデリング 「解決すべき問題から見た物事の捉え方
このエントリは Ruby on Rails Advent Calendar 15 日目です。(遅くなってすいません) 同時に 14 日目のじょーかーさんのエントリへのアンサーエントリでもあります。 (まあ、じょーかーさんがこの Advent Calendar に登録したときに、タイトルから内容を推察してこれを書くことを決めましたが、実際のところ、あまりアンサーにもカウンターにもなってないし、全然関係ない内容と言えないこともないので、まあサービスクラスについては僕も推奨したことがあるし、僕も反省してるんですよ程度に読んでもらえると幸いです。) まずはじめにごめんなさい 3 年くらい前に僕は Rails にサービスクラスというものを導入するといいことがあるよと書いたのだけど、それからいくつもの Rails アプリケーションを見たり、実際に自分で開発したりして、うーんって思うことも増えてきたので
あたりを参照。 要は複数層から成るレイヤードアーキテクチャの一種で、レイヤー・要素間の結合性を依存性ルールによって縛り、下記のような恩恵を期待する。 恩恵 アプリケーションをフレームワークから独立させる。フレームワークによって提供されている機能や設計に依存せず、同時にフレームワークの制約に縛られない。 テストを容易にする。各レイヤー・要素を独立して動作させる。ある一つの要素のテストのために、他の要素を用意する必要がない。 UIに依存しない。UIがブラウザではなくCLIになったとしても、ビジネスルールを変更する必要がない。 データベースに依存しない。OracleやMySQLを問題なくMongoやPostgresQLに置き換えられる。Webのクライアントとしては、永続化層に依存しない。Web APIのURLやリクエストパラメータが変わったとしても置き換えられる。また、Web APIではなくLo
おはこんばんにちは、かとじゅんです。 久しぶりにブログを書く…。最近、趣味でAngular2やらReactやらやっています。やっとWebpackになれました…。 さて、今回のお題は「FluxとDDDの統合方法」について。Angular2を先に触っていましたが、FluxといえばやはりReactだろうということで途中で浮気してReactで考えています。Angular2でもできるはずですが、今回はReactで統合方法*1について考えてみたいと思います。一つ断っておくと、FluxはDDDと統合することを想定していない設計パターンなんで云々とかはここでは考えていません。それはこのブログ記事を読む読まないに関わらずご自身で判断されてください。ソースコードについては、Githubへのリンクを一番下に書いてあるので興味がある人は参考にしてみてください。 Fluxって何? まず基礎ということで、Flux i
スタートアップ企業が実践する「身の丈スクラム」の現在地 / Current State of 'Right-Sized Scrum' Practices in Startups
CleanArchitectureを使ったサンプルアプリを作成したので、説明していきたいと思います サンプルアプリ まず、作成したアプリについてです Qiitaのクライアントです 認証 投稿一覧 詳細 ユーザー投稿一覧 詳細 ソースコード https://github.com/hachinobu/CleanQiitaClient 使い方 一応そのままビルドしてもビルドは通りますが認証していない状態なのでAPIコール制限とストックボタンなどは動かないです 認証したい場合は下記からアプリケーションの登録をしてください https://qiita.com/settings/applications/new リダイレクト先のURLをサンプルソースコードでは固定にしてしまっているので clean-qiita-client://oauth で登録すると楽です Client IDとClient Secr
autoscale: true theme: Plain Jane,5 複雑なJavaScriptアプリケーションを考えながら作る話 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info #jsprimerを書いています JavaScript入門書に興味ある人はウォッチ :star: :warning: 注意 :warning: 作成するアプリケーションによって必要な構造は異なります 今回の話はある程度の規模で複雑性を持つクライアントサイド ライブラリ抜きで数万LOC >= 長期的にメンテンナンスや変更が発生するアプリケーション サーバサイドレンダリングはしないクライアントアプリケーション 3行でOK 複雑なJavaScriptアプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した
DDD 関連の書籍といえば、Eric Evans の DDD 本( エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) )や、Vaughn Vernon の IDDD 本( 実践ドメイン駆動設計 (Object Oriented SELECTION) )が有名です。 DDDで登場する実装パターンや周辺知識をより実践的に解説しているのが、「.NETのエンタープライズアプリケーションアーキテクチャ 第2版 (マイクロソフト公式解説書)」(naa4e)です。 .NET 以外にも大いに通じる内容 本書は、.NET の名を冠しており、サンプルコードは、C# で記述されています。また、利用するライブラリも .NET 周辺のものであったり、解説で登場する RDBMS も、Web 系でよく登場する MySQL や PostgreSQL よりも、S
Reactive Messaging Patterns読書会のなかで、「マイクロサービスとAkkaとGo」な面白い話題が出たので代表でまとめる試みエントリです。(結構、色々な話題に飛んでいるので難度高い。) まとめ方としては、会話ログを転記して、最後にまとめる形をとっています。また、議論と私の考えが混ざらないように所感は分けておきます。 ddd-cqrs-es.connpass.com TL;DR 要素技術(どんな言語使うとか、どんなアーキテクチャにするとか)の前に、組織やプロダクトの性格を考えて戦略を決めましょう。 そして、その中で最適と思われる戦術をとれるような要素技術を採用しましょう。 Akka良いよ。 ログ(一部抜粋) Slackからの引用のためテキストベースです。 事の始まりは、荒木さん(以下、 @applideveloper )の発言でした。 (この記事絡みですね。 集合知で各
この定義がどうあれば正しいかは、ドメインエキスパート というその関係する領域の知識を多く持つ人(業務知識を豊富に持つ人なので、この場合だと病院関係者の中でも診察予約にもっとも精通している人なので、看護師の代表者かと)とソフトウェアエキスパート(設計や実装の知識をもっとも持つ人)の会話から抽出と定義を繰り返します。 さらに設計や実装をすすめたり、実際にアプリを使ってもらう中で誤りがあれば正しく変更していきます(リファクタリング)。 ドメインドリブンデザイン(ドメイン駆動設計) DDD = Domain Driven Design ここまで説明してきた、ドメインモデルとユビキタス言語。これを明らかにしていくだけではDDDではありません。俺たちの本当のはじまりはここから。ソフトウェアは実装して使ってもらってなんぼです。つまりこのドメインモデルをオブジェクト志向プログラミングの オブジェクト にし
All slide content and descriptions are owned by their creators.
単方向にする DDD には一方向の関係性が適しています。Eric Evans は、「可能な限り関係性を制限することが重要です」、そして「ドメインを理解することで自然な方向性が明らかになります」と助言しています。 - データ ポイント - ドメイン駆動設計のコーディング: データを重視する開発者のためのヒント (第 3 部) DDDにおいては 関連を極力排除する のが正しいようだ。たとえば「伝票」と「明細」からなるaggregateについて。まずaggregate rootである「伝票」が グローバルなIDをもつ 。関連は「伝票」から「明細」の向きにある。つまり「伝票」オブジェクトが「明細」オブジェクト(のコレクション)を参照する。逆はしない。「伝票」は「伝票リポジトリ」にある(リポジトリから取得する)。 class Slip { UUID id; List<Detail> details
プロダクト拡大フェーズでプロダクト検証サイクル効率化を目指す過程で見えたもの / Streamlining Product Validation in Growth Phase
自分用のメモ TL;DR ドメイン駆動設計の知識をエヴァンス本を等を読んで学び、現場で実践していくことが大切 チームメンバーと一緒に実践していくなら、お手本を見せていくことが大事 顧客の関心事を理解し、実装していくことが大切 オブジェクト指向とエクストリームプログラミングのプラクティス等を活用する イベントページ http://ddd-alliance.connpass.com/event/21932/ ビッグローブでの2年間の取り組み DDDを組織で始めるための考え方 途中から参加 現場 ←→ 経営層 相手の立場になると「あーわかるわー」ってなることがあるので、そこを汲み取って行くのが大事 開発現場から学んだドメイン駆動設計中心のサービス開発 DDD適用サービス Wi-Fiスポットから 5チーム30人でDDD実践 100名規模でやっていきたい DDDの価値を共有 課題分析と課題解決 人材
ddd-zk.connpass.com DDD座談会のパネラーとして登壇させていただきました。 素振り 予め参加者の方々からいただいた質問(テーマ)に対して、予行練習というか、ちょっと自分の考えを先にまとめていたのですが、予想通りテーマひとつひとつが盛り上がったので全部を話しきることができませんでした。 折角なのでここに公開しておきます。 ところどころ、座談会終わっての後書きも追記しています。 なお、あくまで私見ということでよろしくお願いします。座談会のまとめ記事というわけではありませんので、悪しからず。 各人のコンテキストで、こんな解釈あるよ等あると思いますので、Twitterでもコメントでもフィードバックいただければ幸いです。 DDD全般について DDDに向いている要件とは?費用対効果ってどうなの? 継続的に投資したいプロダクトであることが大事だと思っています。 システムは一度作れば費
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く