『ソフトウェアアーキテクチャの基礎』 - Techmee vol.2 での発表資料です https://timeedev.connpass.com/event/254336/ 動画: https://youtu.be/ydQ2xoc49Lc #Techmee
Androidアーキテクチャことはじめ ― 選定する意味と、MVP、Clean Architecture、MVVM、Fluxの特徴を理解する Androidアプリの開発において悩ましいアーキテクチャの選定。本記事では選定する意味を改めて整理し、 MVP・Clean Architecture・MVVM・Fluxといった最新の実例を紹介します。 はじめまして。Androidエンジニアの藤原聖(ふじわら・さとる/@satorufujiwara)です。 現在は株式会社サイバーエージェントで、エンジニアリングマネージャーを兼任しています。2017年で35歳になり、定年を迎えました(プログラマの定年については「体型を支える技術」などを参照)。 Androidアプリ開発には2010年から携わっていますが、今現在の関心事は何といっても公式開発言語に採用されたKotlin。そしてもう一つが、Androidの
Clean ArchitectureにはUseCase層が定義されていますが、このUseCaseが一体どういうものなのか度々わからなくなるので、自分の考えをまとめてみるエントリです。 Clean Architectureについてはこちら 8thlight.com 日本語訳:クリーンアーキテクチャ(The Clean Architecture翻訳) 以降、概念を”ユースケース”、実装されるモノを”UseCase”と表記することにします。 (同じっちゃ同じなんですが、指してるものがところどころ変わるので表記分けをしています。) また、Webアプリケーションを想定しています。 ユースケースとは何なのか Clean Architectureから抜粋します。 Use Cases The software in this layer contains application specific busi
(追記) 本記事,頭のなかを整理しきれていない状況で書いたためよくわからないことになっていますが,Clean ArchitectureやRedux,DDDの優位な点を解説するような記事ではないことをご了承いただけると幸いです. 全体の構成がどうなっているか・モチベーション・pros・cons等については後日別記事にまとめようと考えています. いま書いているアプリがClean ArchitectureになりそこねたMVPと中途半端なDDDを組み合わせたようなアーキテクチャになっている. このアプリをある程度キチンとClean ArchitectureとDDDに寄せるにあたり,DDDのレイヤ分け(Data/Domain/Presentation)をどこまで厳格にやるかで悩んでいる. 現状 だいたいこんな感じ. Data/Domain/Presentationのすみ分けはしていない 実装上は意識
Android開発していると、なんかMVCうまくいかないなぁとモヤモヤしてきました。そろそろ他のアーキテクチャを模索してみた方がいいんじゃないかと思い始めまして、ある程度考えがまとまったので自分なりの指針を残しておこうと思います。 そもそもアーキテクチャ必要なのか 世の中には色々なアーキテクチャが存在するんですが、なんか概念を読んでもスッと理解できることが少ないんですよね。これはなぜかと言うと アーキテクチャが解決しようとしている問題を理解できないからです。 極端に言うと、HelloWorldを表示するアプリにMVCを導入する必要があるの?って言うと答えはNoですよね。じゃあ猫の名前をリストで表示するアプリだったらどうかと言われると、これもまだ必要ないかもしれません。 つまり、アーキテクチャを適用しなくても問題がないほど小さなアプリにおいては、ただ冗長になるだけなので別にいらないわけです。
はじめまして。 6/1より入社いたしましたAndroidエンジニアの釘宮です。よろしくお願いいたします。 今日はAndroidの設計について語ってみようと思います。 その前に 「良い設計とはなにか」という議論が「正義とはなにか」という議論のようにいつまでたっても結論がでないのは、環境やチームメンバのスキルセット、ステークホルダーによって目指すべきゴールが変わるためだと考えます。 つまるところ、設計に正解はありません。 そのため以下で話すことは、「これが設計の正解だ!!」というわけではなくて、「こういう設計の仕方するとうまくいくっぽい」くらいのノリです。 あと、特にMVCとかDDDとか人によって解釈のズレが起きやすいところなどは、冗長になるのを嫌って自分の解釈で言い切っています。ご了承ください。 設計の目的について ハードルが下がったところで、早速。 まず設計の目的ってなんでしょうか? この
2013-06-24 2012年4月23日にテキサスの Austin で行われた RailsConf 2012 での Rich Hickey (@richhickey) さんによる基調講演、Simplicity Matters を書き起こして翻訳しました。 Rich Hickey さんは Clojure や Datomic の作者です。 この翻訳は Creative Commons Attribution ShareAlike 3.0 ライセンスに基いて公開します。 Rich Hickey 講演 e.e d3si9n 訳 談: こんにちは。ご招待いただきありがとうございます。 聞く所によると RailsConf はいつもコミュニティーからかなり外れた人を選ぶらしく、今回は僕ということになりました。 僕の電話ボックスは外に駐車してあります。(会場、笑) だけど、今日は言語の壁を越える話題を持
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く