Modeling Forum 2018 技術公演トラックで発表した内容となります。 VernonVaughn Vernon 氏が発表 した書籍「 実践ドメイン駆動設計（通称： IDDD ）」の 流れに沿って、 DDD の基本からモデリング手法までを 幅広く紹介します。Read less

ChatWork社内勉強会で発表した際の資料

はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: https://nrslib.com/bottomup-ddd-2/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 セミナー情報 こちらの内容のセミナーを不定期で開催しています。 ◆セミナーページ 第一回: https://ddd-community-jp.connpass.com/event/103428/ 第二回: https://ddd-community-jp.connpass.com/event/107106/ 第三回: https://nrs-seminar.connpass.com/event/117283/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は

バージョン Python 3.7.0 目次 値オブジェクトの説明 値オブジェクトのルール 値オブジェクトを作る理由 参考文献 おまけ 値オブジェクトの説明 値オブジェクトとは、「一意に識別して変更を管理する必要がないモノ」。 適切に設計していれば、値を想定外に書き換えられてしまうリスクがなくなり、安心して開発ができます。 値オブジェクトのルール 値オブジェクトを作るときのルールが3つ存在します。 状態を変更不可能にする 同一の値オブジェクト同士を同じオブジェクトと判断できる 交換可能である 状態を変更不可にする pythonでイミュータブル(変更不可)なクラスを作るには、dataclassを使うと良いでしょう。 ただ、dataclassはpython3.7から使用可能です。 (dataclassに関して参考になる記事) import dataclasses @dataclasses.dat

Developers Summit 2023 9-D-1「もう悩まされない開発環境、プロジェクトで統一した環境をいつでもどこでも」Kazumi IWANAGA

この記事は一休.comアドベントカレンダー2017の10日目です。 システム本部 CTO室 エンジニアの @yu-sa です。 今回はとある開発で、ドメイン駆動設計で,インターフェース指向を意識した環境での開発に携わった際の知見を記事にさせて頂きたいと思います。 自分は今まで、SmartUIな開発ばかりしてきたため、今回の開発では多くを勉強させていただきました。そんな経験談や調査内容をまとめて共有したいと思います。 参考記事 ドメイン駆動設計の道標 Python におけるドメイン駆動設計(戦術面)の勘どころ [DDD]ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく 最後のまとめをはじめに アーキテクチャと実装例を見て、ドメイン駆動設計のイメージを理解。 ユビキタス言語についての理解を深める。 ドメイ

DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か 背景 ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かの記事で、オススメしていたのはオニオンアーキテクチャでした。 今回は、オニオンアーキテクチャについて詳しく説明したいと思います。 上述の記事でも書いた通り、「ヘキサゴナル、オニオン、クリーン」の3つは、本質的には全く同じで、思想としてはヘキサゴナルで完成されているのですが、より具体的に説明されているオニオンアーキテクチャから説明を読んだ方が理解がしやすいと思います。 その後にヘキサゴナルの説明を読むと「なるほど」となって「あれ、結局ヘキサゴナルじゃん」と

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

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

背景 直近のプロジェクトでDDDの思想に則ったアーキテクチャで一つリリースまで漕ぎ付けまして、そこに至るまで色々と調べたり試行錯誤をしながら学んだことを書いていこうと思います。 一番にですね、大体のDDDに興味を持った人がいうのが 「単語が難しいばかりで結局イメージが湧かない」 「ドメイン駆動の本を読もうとして速攻で心が折れた」 ということなんですよね。 DDDは思想としてすごく面白く、とても実用性なものなのに、なんでこんなにわかりづらいのか、ハードルが高いのか！！ という点について、私なりの解釈を述べたいと思います。 心をくじく要因 Eric Evans本は説明が圧倒的に下手。笑 ドメイン駆動設計といえば原著がこの本(以下、原典)なのですが、 エリック・エヴァンスのドメイン駆動設計 この本は本当〜〜〜にわかりづらいです。重要なことは確かに書いてあるんですが、構成がかなりしんどくてまとまり

なめらかな世界と、その敵 作者: 伴名練,赤坂アカ出版社/メーカー: 早川書房発売日: 2019/08/20メディア: 単行本この商品を含むブログを見るこの『なめらかな世界と、その敵』を端的に紹介すれば、ＳＦマニアからビギナーまであらゆる層を満足させる、オールタイム・ベスト級の傑作ＳＦ短篇集である。とはいえ著者伴名練の名は、ＳＦファン以外は聞いたことはないだろう。既刊行作は『少女禁区』という約10年前に刊行された中短篇集一冊のみで、その後も企画物のアンソロジーに散発的に短篇を発表しるのみだったから、普通は知る機会は多くはない。 だが、ＳＦファンの間では、本書の刊行前から伴名練の名は異常なほどの熱気でもって知られていた。というのも、商業発表作こそ少ないものの、同人誌に毎年のように新作短篇を発表しており、その作品の出来がまた凄まじかったからだ。それまでのＳＦの先行作を緻密かつ複雑に折り込み、舞

※この投稿は米国時間 2019 年 6 月 20 日に Google Cloud blog に投稿されたものの抄訳です。 私たち Google Cloud は、Google Cloud Platform（GCP）上に移行もしくは構築されるアプリケーションの最終目標として、よく「クラウドネイティブ アーキテクチャ」という言葉を使います。では、クラウドネイティブとは正確にはどういう意味なのでしょうか。そして、そのようなシステムはどうすれば設計できるのでしょうか。 大まかに言えば、クラウドネイティブとは、クラウドによってもたらされる、従来のオンプレミスにはない新しい可能性に適応することを意味します（アーキテクチャ上の制約も従来とは大きく異なるため、それにも適応）。ソフトウェア アーキテクトとして私たちが考慮するよう訓練を受けている高レベルの要素について考えてみましょう。 システムの機能要素（何を

はじめに アーキテクチャや設計の書籍や記事、これまでの経験も踏まえ、学んだ事をここにまとめたい。(まだ、勉強中なので微妙なところもあるかもしれません。お気付きの点があればご指摘いただけるとありがたいです。) 参考文献や参考記事は、本当に良書、良記事で非常に参考にさせていただきました。 生意気なタイトルにしてしまいましたが、自分への戒めということもあってこのタイトルにさせていただいたので、ご容赦ください。 ある共通した話題 設計やアーキテクチャについて書かれた書籍や記事を読んでいく中で、言葉は違えどかなりの高確率で共通するテーマが存在した。 そう、それが 「変更に強くなろう」 といった趣旨のテーマだ。 アーキテクチャや設計に関する書籍や記事は様々な方法論で、これを実現しようとしていた。 今回のテーマと記事の構成 今回は、「変更に強くなろう」というテーマの中で重要だと感じた概念や考え方をまとめ

最近何かと騒がしいクリーンアーキテクチャですが、丁度プロダクトで採用したところだったので折角なので情報共有ということで 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アプリケーション）：

1. 株式会社ブレインパッド 2019年2月15日 @ デブサミ 2019 機械学習システムのアーキテクチャ アラカルト ～ BrainPad における実例を交えて～ 1 2. 太田 満久 ● Deputy General Manager @ BrainPad Inc. ● Google Developers Expert (ML) ● Organizer of TensorFlow User Group. ● A Steering Committee of MLSE ● A Committee of JDLA 4. © BrainPad Inc. BrainPad: 最高の価値提供を可能にする3つの力 2004年の創業以来、ブレインパッドがデータ活用をお手伝いした企業は800社を超えま す。幅広い業界を対象として、豊富に積み上げられたナレッジを武器に、お客様の経営課 題を　解決に導きます

はじめに Amazon Auroraは、AWSを触る人ならほとんどの人が利用を検討したことがあるでしょう。 Amazon社内ではOracleを止めたというtweetもありました SHUTDOWN ABORT the last Oracle database running Amazon Fulfillment! pic.twitter.com/DorqTua2Lt— John Darrow (@jdarrow) 2019年3月29日 そんなAuroraは、従来のRDBとは違いクラウド上で動くことを念頭に設計されています。 また、ログが中心的な役割を持つことから「The log is the database」と表現されることもあります。 そんなAuroraの仕組みについての論文を読んだので紹介します。 読んだ論文は以下の２つです。 Amazon Aurora: Design Conside

第６回ゲームサーバ勉強会用資料です。 Webの技術の根幹となるHTTPやTCP/IPを軽くおさらいしたあと、 マルチプロセス、マルチスレッド、イベント駆動といったサーバアーキテクチャについて解析し、 さらにイベント駆動を実現するための非ブロッキングI/OとI/Oの多重化について解説します。

こんにちは、小林（@koba04）です。 本記事では、シングルページアプリケーション（以下、SPA）における状態管理について解説します。 GmailやTwitterは、SPAとして構築されている代表的なWebアプリケーションであり、スムーズなページ遷移をSPAによって実現しています。またElectronやPWA（Progressive Web Apps）の登場により、複雑なアプリケーションをWebの技術を使って構築する場面も増えてきました。 これらの複雑なアプリケーションにおいては、既存のページ単位での状態管理の考え方では対応が難しくなります。 そこで今回は、具体的なフレームワークも取り上げながら、Webフロントエンドにおける状態管理のアプローチについて紹介します。 フロントエンドでの状態管理の複雑化 ページの単位を超えた状態の保持 モデルとビューによる処理の分割 イベントの管理が複雑にな

When people in the software industry talk about “architecture”, they refer to a hazily defined notion of the most important aspects of the internal design of a software system. A good architecture is important, otherwise it becomes slower and more expensive to add new capabilities in the future. Like many in the software world, I’ve long been wary of the term “architecture” as it often suggests a