You are also opting in for interesting, DDD-related emails from buildplease.com
楽に開発するためにAndroid全体の設計をしたいという思いは、わりとどの開発者も持っている気持ちだと思う。 設計というのは昔から色々揉まれてきて、今はMVPだMVVMだ、DDDだと盛り上がっている。 そもそも、Androidというフレームワークに限定された環境で、わりとよくある実装が多い中で、未だにこれだけたくさんの人が困っているという状態がおかしい。おかしすぎる。そろそろAndroidでこういうの作りたいならこう作るでしょ、みたいなベストプラクティスが確立しているべきじゃないのかという気がする。 あくまで個人的にはだけれども、DataBindingが主流になるのであれば双方向バインディングを使ったMVVMが一番しっくり来る。ただ、MVVMだとViewModelが太ってきてどうすんのみたいなことになるかもしれない。また、通信やキャッシュ部分は別のクラスにわけようとかそういう指針はどちらに
Gayathri Thiyagarajan Lead Software Engineer - Capgemini Andrew Harmel-Law Principal Software Engineer - Capgemini Eric Evans’ Domain Driven Design (DDD) is a core text for all developers, and it's experiencing a renaissance due to the rise of microservices. But are most of us really applying DDD when we're "doing" distributed systems development? Gayathri and Andrew are going to argue that we're
ビッグローブでDDDを導入して早2年。 この2年間、ISP事業における主要なサービスをDDDで開発してきて、試行錯誤の連続でした。 今回は、試行錯誤の過程を経て生まれた、実際に実践している ・設計・実装の考え方(ドメインモデルやコード例やDB設計など) ・チーム環境の考え方(開発プロセスやチームビルディングなど) の2つを軸に現場でのリアルな体験を紹介します。 また、最後に、試行錯誤における失敗談も紹介します。 Read less
2016 - 10 - 19 Android版MERYのアーキテクチャ list Tweet こんにちは、普段MERYの Android を開発している栗野です。 最近、 Android アプリMERYでは2.0の開発を行っており、それに伴って Android の アーキテクチャ を見直す取り組みを行っております。 その中で新しく採用し、進めている アーキテクチャ について少し話そうと思います。 ことの始まり Android は今まで1.5人体制で開発を進めていたのですが(一人は iOS との兼務)、少し前から新しい Android エンジニアがjoinし、2.5人体制で開発をすることになりました。 そしてちょうどその方が、「DDDな人」だったこともあるのと、少し前に職場の「DDDな先輩」から「 エリック・エヴァンスのドメイン駆動設計 」を借りて、それを読み始めていたことも重なって、新しい
Cyrille Martraire is a passionate developer since 1999. He's the co-founder and CTO of Arolla, a company specializing in software development and nothing else. With a love-and-hate relationship with documentation, he has experimented over more than 10 years with multiple ways to get smarter documentation, from automation to self-discipline. Addicted to development at all scales, Cyrille still dedi
DomainEvent ドメインエキスパートが「…した『とき』に、こうなる。」とか。 何かの状態変更をトリガーにして、別の処理をしたい場合にドメインイベントを使う。 イベントオブジェクトがイベントの情報を運んでくれる。 source data & processing data Domain Event ドメインイベントはイミュータブルな「source data」とミュータブルな「processing data」で構成される。 source dataってのは「イベントが発生した」という部分の情報で、これは一旦作成されたら変更されることはないよね。 processing dataは「システムがこのイベントをどうしたか」って情報ね。分けてもいいかもね。 Aggregate & DomainEvent DDDでは、1つのユースケース(トランザクション)で触ってイイ集約は1個だけ。なんだよね。 だ
All slide content and descriptions are owned by their creators.
1. 株式会社ネクストスケープ 御中 青木 淳夫 & 上坂 貴志 Sansan DDD勉強会 #2 http://connpass.com/event/23174/ 2015.12.16 「実践ドメイン駆動設計」社内読書会まとめ ~IDDD本難民に捧げる1章から7章~ 3. 3 大手SIer、テクニカルライター、福井のWebデザイン会社を 経て、ネクストスケープ所属。 プログラマーとしてシステム開発の難しさを感じていた2000 年頃、XPとvbUnitに出会い、アジャイルに傾倒。 その後、Javaでの大規模ウォーターフォール案件でチームリ ーダーを経験したり、Web制作会社でPHPを書いてみたり。 最近はデジタルマーケティングやクラウドソリューションに 携わったりすることが多い。 Microsoft MVP for Visual Studio(2006~) Sitecore MVP(201
『エリック・エヴァンスのドメイン駆動設計』は、2003年の刊行だったにもかかわらず、大型ソフトウェア構築時につきまとう不透明感を払拭するための指針として現役技術者に多大な影響を与えた。ある意味、エリック・エヴァンスの先見性によって、今日、必要とされるパタン/アンチパタンが整理されていたためだ。 とはいえ、それからすでに11年。ベースとなるオブジェクト指向はそれほど大きな変革はないものの、この10年の間にコンピューティングの対象は大きく増え、さらにドメイン駆動設計をコトバでは知っているものの、経験値のまだ低い技術者の増加もあり、理論だけではなく現状に則した形で体得する必要性が増している。 本書はDDDの考え方はもちろん、コミュニティや実際のビジネスシーンのなかから実践的な方法論を精錬し、いわば21世紀(初頭)型ドメイン駆動設計を伝授するものであり、現在のニーズに合致する内容で構成されている。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブ
Domain-Driven Design Reference Definitions and Pattern Summaries encapsulate with MODEL-DRIVEN DESIGN express model with isolate domain with encapsulate with ENTITIES VALUE OBJECTS LAYERED ARCHITECTURE AGGREGATES REPOSITORIES act as root of FACTORIES encapsulate with express model with encapsulate with access with encapsulate with access with DOMAIN EVENTS express model with SERVICES push state c
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く