クリーンアーキテクチャで値オブジェクトをユースケースのアウトプットに使ってもいいか？ - Qiita
疑問だったこと クリーンアーキテクチャでEnterprise Business Rules層の値オブジェクトを、Interface Adapter層にアウトプットとして直接渡していいか？ それとも、Application Business Rules層で値オブジェクトの中身をデータストラクチャオブジェクト(図2のOutput Data)に移し替えてInterface Adapter層に渡したほうがいいか？ 図1 図2 疑問の背景 今回悩んでたのはEnterprise Business Rules層に値オブジェクトが20個くらいあり、それをApplication Business Rules層でデータストラクチャに変換してアウトプットに返すかどうかという点です。実装コードを想像すると、同じコードのクラスがいくつもできてしまう気がして、どちらにするか悩んでました。 値オブジェクトをデータストラ
「実践ドメイン駆動設計」を読んだので、実際にDDDで設計して作ってみた！ - Qiita
こんにちは、クラウドワークスの新規事業のエンジニアとして仕事をしている高梨です！ 最近、「実践ドメイン駆動設計」という本を読みました！ 500ページ近くもある技術書で、なかなか量は多かったのですが、DDDがどんなものなのか一通り大枠を掴めた気がします。 ただ読み終わった後にこんな疑念や不安をいだきました。 「たしかにかなり面白そうだけど、実際にやるとどれだけ工数かかるんだろう...？」 「設計の話は全然出てこなかったけど、DDDで作るとなるといったい何から始めればいいんだ？」 「戦術についての知識はついたけど、実際に書こうとしたらできなそうだな...」 そこで、そういった疑念や不安を解決するために、実際にDDDでサンプルプロダクトを作ってみようと思ったわけです。 実際に作ってみるのが、結局一番理解が進みますしね。 今回は、そのプロダクトがリリースされるまでの過程や感想を、作成した設計書やソ
新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 以前こちらの記事でアプリケーションアーキテクチャについて書きました。 こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。 そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。 結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。 アプリケーションアーキテクチャ全体図 とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。 何かについて議論をする際は、 「それはどの層の責務なの？」 という
![新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/da075520c5346bf5227bf90557a35ccf8b5b07ae/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20181210%2F20181210195849.png)
集約の境界と整合性の維持の仕方に悩んで2ヶ月ぐらい結論を出せていない話 - kbigwheelのプログラミング・ソフトウェア技術系ブログ
本記事はドメイン駆動設計 Advent Calendar 2018 - Qiitaの3日目の記事です。 2日目は、grimroseさんのぐるぐるDDDで気をつけてることでした。 4日目は、s_edwardさんのMicroservices と DDDです。 Table of Contents Table of Contents 以下の記事を読むにあたり前提となる知識 問題 サービス詳細 ユビキタス言語 重要なビジネスルール モデリング 上の何が問題？ 解決策 解決策1 集約をマージする 解決策2 一時的な整合性の破綻を受け入れ結果整合性を使う 解決策3 アンチパターンではあるが集約間の整合性維持のためトランザクション制御を用いる 解決策4 ユースケースの見直しによる再モデリング まとめ とりあえず今どうやっているか 最終的にどうするべきだと考えているか(2018/12/01時点) ソリューシ
設計のための、問題の捉え方〜ドメイン知識の暗黙知を形式知に〜(まとめ版) - Speaker Deck
「2018/11/8 設計Night2018 powered by Classi」で発表した資料です 当日の資料のページ数が多すぎた(140ページ）ので、2/3くらいにまとめました
技術書典5にサークルとして参加します。 - pospomeのプログラミング日記
技術書典5にサークルとして参加することになったので、 書籍の詳細についてまとめました。 techbookfest.org [追記] BOOTHから購入できるようにしました。 pospome.hatenablog.com 書籍のざっくり情報は以下です。 書籍の目次はこちら サーバサイドのアプリケーションアーキテクチャに関する書籍 ページ数は155ページ PDF版のみ 価格は1冊1000円 購入していただけるとその場でQRコードが印刷されている紙を渡すので、そこからPDFをDLしてください。 サンプルコードはGo言語ですが、サーバサイドのアプリケーションアーキテクチャがメインなのでサーバサイドのアプリケーションエンジニアであればGo言語に関わらず役に立つはず かんたん後払いには対応していません 当日まで可能な限り内容を精査するので、内容が一部変更されるかもしれません。 当日は見本誌を用意するの
実装クリーンアーキテクチャ
最近何かと騒がしいクリーンアーキテクチャですが、丁度プロダクトで採用したところだったので折角なので情報共有ということで Qiita の初記事にしてみようと思います。 こちらの記事は GUI や CUI のアプリケーションを対象にしています。 Java コードの記事リンク：https://nrslib.com/clean-architecture-with-java/?preview_id=1263&preview_nonce=542ba7b70f&_thumbnail_id=1293&preview=true その他解説もしています。もしよろしければチャンネル登録をお願いいたします。 より実践的なコード（WEBアプリケーション）: https://github.com/nrslib/itddd/tree/master/CleanLike YouTube での解説（WEBアプリケーション）：
DDD - What, why, how?
Many people who start exploring Domain-Driven Design (DDD) are wondering what it's all about. Some argue that all those implementation pattern are important. Others say that these patterns should have been excluded from the Blue Book in sake of strategic design. I mostly agree with the latter and explain why in this presentation. It was presented at the first DDD Norway meetup in Oslo, on the 1st
Sagas - Airplanes. Cloud Computing. And Alien Abductions.
Football. Cloud. Tech. Politics. Pictures. Principal Architect for Messaging/Eventing at Microsoft. Today has been a lively day in some parts of the Twitterverse debating the Saga pattern. As it stands, there are a few frameworks for .NET out there that use the term "Saga" for some framework implementation of a state machine or workflow. Trouble is, that's not what a Saga is. A Saga is a failure m
Why Use an Event Aggregator?
a place for me to talk about programming and .NET ... because my friends and family aren't interested All programs need to react to events. When X happens, do Y. Even the most trivial “Hello, World” application prints its output in response to the “program was started” event. And as our programs gain features, the number of events they need to respond to (such as button clicks, or incoming network
エンティティの識別子をラップしたクラスを用意するとよい理由 | GuildWorks Blog
ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。 今回は、ドメイン駆動設計における、エンティティの識別子の実装面について考えてみたいと思います。（あまり本質的な話題でなくてすみません。。。） エンティティの識別子、どう実装していますか？ 私の場合、以下の図のようにエンティティが直接LongやStringなどプリミティブの型で持ってもよいと思っていました。エンティティの識別にしか使われないのでエンティティが直接持っていた方が使いやすいと思っていたのです。 ドメイン駆動設計本の例はどうでしょう・・・。 ドメイン駆動設計ではプリミティブの型を使用している例も載っていますが、書籍内のサンプルを実装したDDDSampleではVoyageNumberやTrackingIdなど識別子をラップしたクラスを使ってます。 実践ドメイン駆動
[ Android ] - これからの「設計」の話をしよう | PSYENCE:MEDIA
はじめまして。 6/1より入社いたしましたAndroidエンジニアの釘宮です。よろしくお願いいたします。 今日はAndroidの設計について語ってみようと思います。 その前に 「良い設計とはなにか」という議論が「正義とはなにか」という議論のようにいつまでたっても結論がでないのは、環境やチームメンバのスキルセット、ステークホルダーによって目指すべきゴールが変わるためだと考えます。 つまるところ、設計に正解はありません。 そのため以下で話すことは、「これが設計の正解だ！！」というわけではなくて、「こういう設計の仕方するとうまくいくっぽい」くらいのノリです。 あと、特にMVCとかDDDとか人によって解釈のズレが起きやすいところなどは、冗長になるのを嫌って自分の解釈で言い切っています。ご了承ください。 設計の目的について ハードルが下がったところで、早速。 まず設計の目的ってなんでしょうか？ この
![[ Android ] - これからの「設計」の話をしよう | PSYENCE:MEDIA](https://cdn-ak-scissors.b.st-hatena.com/image/square/ee7f3c3732f2b9a1d556123c9b7490ad783ac009/height=288;version=1;width=512/https%3A%2F%2Fs3.ap-northeast-1.amazonaws.com%2Ftechblog.bucket%2Fwp-content%2Fuploads%2F2014%2F11%2Feyecatch-android.jpg)
4.2. ドメイン層の実装 — TERASOLUNA Server Framework for Java (5.x) Development Guideline 5.0.1.RELEASE documentation
4.2.1. ドメイン層の役割¶ ドメイン層は、 アプリケーション層に提供する業務ロジックを実装するためのレイヤとなる。 ドメイン層の実装は、以下3つに分かれる。
【Swift】DDDを取り入れたiOS開発 その1 ~UseCaseとdelegate~ | PSYENCE:MEDIA
この記事は RECRUIT MARKETING PARTNERS Advent Calendar 2015 の投稿記事です。 こんにちは。英語サプリのiOS担当の大島です。英語サプリは10月末にリリースしたばかりのサービスで、アニメーションやBGM・効果音を取り入れたゲーム感覚の英語学習アプリです。iOS版とWeb版がリリース済みでまだサービスは始まったばかりですが、開発期間も短い中でクオリティにこだわってローンチすることが出来ました。当エントリでは、iOSアプリケーションの設計手法について紹介していきたいと思います。 DDD（ドメイン駆動設計）で複雑さと戦う 複雑なiOSアプリケーション開発をしていると以下のような問題点で悩まれているエンジニアの方も多いのではないでしょうか。 すぐにFatになってしまうUIViewController 複数のフラグで状態を管理するUIViewContro
Clean Architecture + DDD + Redux + RxJavaをAndroidでやるときにどこまで分割するか問題 - Augmented Usamimi
（追記） 本記事，頭のなかを整理しきれていない状況で書いたためよくわからないことになっていますが，Clean ArchitectureやRedux，DDDの優位な点を解説するような記事ではないことをご了承いただけると幸いです． 全体の構成がどうなっているか・モチベーション・pros・cons等については後日別記事にまとめようと考えています． いま書いているアプリがClean ArchitectureになりそこねたMVPと中途半端なDDDを組み合わせたようなアーキテクチャになっている． このアプリをある程度キチンとClean ArchitectureとDDDに寄せるにあたり，DDDのレイヤ分け（Data/Domain/Presentation）をどこまで厳格にやるかで悩んでいる． 現状 だいたいこんな感じ． Data/Domain/Presentationのすみ分けはしていない 実装上は意識
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
似非サービスクラスの殺し方 / #ginzarb
NodeJS and Good Practices Separation of concerns doesn’t need to be boring - The Miners