メモ:値オブジェクトの定義と差異について - かとじゅんの技術日誌
「値オブジェクト」の定義について不勉強だったので「DDDの値オブジェクト」の定義とDDD以外の「値オブジェクト」との違いについて、改めて関連書籍を読み直し整理してみました。 すごい長いし細かいので他人に読ませるような記事ではなく、自分のために書いたメモです。 もし読むなら興味がある人だけで。 自分向けのメモですが、一応 この記事の前提や意図を書いておきます。 「DDDの値オブジェクト」以外を否定する記事ではありません。 原理主義のように書籍の理想どおり実践するべきだと主張するつもりはありません 「理想に従えばよい」「理想に従うの無意味だ」と決め付けの二項対立的な思考ではなく、理想と現実の絡み合ったグレーゾーンを見極めつつ、現場で手を打つのが優れた実践者ではないでしょうか 下記に紹介する、それぞれの値オブジェクトの優劣について細かく議論し、論破する・されることを目的としていません。 言い訳と
Rustを使ってスケーラブルなプログラムを書く方法 - かとじゅんの技術日誌
この記事はRust Advent Calendar 2021の12/24日の記事です。 仕事ではScalaを使っていますが、趣味のプログラミングではRustで書いたものが増えました。Rustは楽しいですね。 今回は、Rustでオブジェクト指向プログラミングに関数型デザインを導入することで、スケーラブルなプログラムを書く方法(スケーラブル・プログラミング)について書きます。 「スケーラブル・プログラミング」といえばScalaです。Scalaの「スケーラブル」という言葉には「小さいプログラムも大規模なプログラムも同じ概念で記述できるべきである」という、柔軟性や拡張性を重視した設計の意図が込められています。それを実現するために必要なものは、オブジェクト指向と関数型を組み合わせたマルチパラダイムな設計です。 Scalaはマルチパラダイム言語の先駆者(今も先頭を走り続けています)ですが、他の言語にも
Rustで真に安全なプログラムを書く方法 - かとじゅんの技術日誌
この記事はRust Advent Calendar 2021の12/8日の記事です。 Rust前提の記事として書きましたが、他の言語にも適用できる考え方なので、ほかの言語勢の方々もよければお付き合い下さい。 今回のテーマは「Rustで真に安全なプログラムを書く方法」についてです。 「真に安全なプログラム」の定義は以下とします。 挙動が安定し、結果が予測可能となる 正しさの基準に基づき、プログラムの間違いを検知することができる 「真に」とはドメイン知識に基づく正しさという意味です。詳しくは後述します。 それと「そもそもRustで実装されるプログラムは安全じゃないのか」という想定質問については「メモリの操作は安全。だが、それだけでは真に安全なプログラムにはならない」が答えになります。これについて興味がある方、ぜひ最後までお付き合いください。 「真に安全なプログラム」を実現するレシピとしては「関
外部キー制約は何も考えずに適用するとよくない - かとじゅんの技術日誌
このブログが話題になってますね。制約を付けること自体はよいことだけど、無目的に適用すると害も生じると思います。 無目的という言い方はおかしいな…。外部キー制約をどのように使えばいいのか、逆にどんなときに使うとまずいのかを考えてみたいと思います。 tech.tabechoku.com 例えば、これ。外部キー制約はできるだけ付けるとか、何も考えずに付けるとよくないと思います。 外部キー制約は、可能な限りつけるようにしています。 DBが別れている場合、外部キーはもちろん貼れないのですが、そうでない場合はとにかく何も考えず貼っています。データベース設計の際に気をつけていること - 食べチョク開発者ブログ テーブル設計をシミュレーションする いいたいことの結論はこれ。以上終了なのですが、もう少しわかりやすく書いてみよう。 何も考えずに外部キーを貼るのは良くないな。トランザクション境界の外で結果整合性
Getter/Setterを避けて役に立つドメインオブジェクトを作る - かとじゅんの技術日誌
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでます。モデリングに関しては成分薄めですが、よい本だと思います。はい。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 作者: Robert C.Martin,角征典,高木正弘出版社/メーカー: KADOKAWA発売日: 2018/07/27メディア: 単行本この商品を含むブログを見る 本書の大筋から少し逸れるが、「5章 オブジェクト指向プログラミング」の「カプセル化」が面白かったので、これを切り口にモデリングについて考えてみる。 OO言語のカプセル化はすでに弱体化している オブジェクト指向の三大要素の一つである、カプセル化について、以下のようなことが書いてあります。 「カプセル化」がOOの定義の一部となっているのは、OO言語がデータと関数のカプセル化を簡単かつ効果的なものにしているから
コードで学ぶドメイン駆動設計入門 〜リポジトリ編〜 - かとじゅんの技術日誌
コードで学ぶドメイン駆動設計入門 〜エンティティとバリューオブジェクト編〜 - じゅんいち☆かとうの技術日誌 コードで学ぶドメイン駆動設計入門 〜振る舞いとサービス編〜 - じゅんいち☆かとうの技術日誌 コードで学ぶドメイン駆動設計入門 〜ファクトリ編〜 - じゅんいち☆かとうの技術日誌 引き続き連投エントリ。私も来年で39歳になります。そして息子が7歳。いいおやじですが、脳は衰えないと言われています。鍛えれば鍛えたほど進化できると信じます。 ということで、リポジトリ編に入ります。 リポジトリ リポジトリは、ライフサイクルの途中から最後にフォーカスし、オブジェクトの永続化と永続化されたそのオブジェクトを検索する手段を提供するオブジェクトです。このように説明すると、DAOに近い印象を持つかもしれませんが、DAOはRDBMSやSQLなどのインフラストラクチャ層の関心事を含んでいるので、ここでは
Scalaの統一アクセス(プロパティ構文)がなかなかイカしてる件 - かとじゅんの技術日誌
今回は統一アクセス(プロパティ構文)がなかなかイカしてる件について。C#とかRuby,Pythonやってる人からすると何を今頃という感じなのですが。 Scalaで統一アクセス(プロパティ構文)を使う Scalaでフィールドを宣言する場合は以下のような書き方になります。 class Employee(name_ : String) { var name = name_ } クライアント側のコードは以下。 val e = new Employee("Kato") e.name = "Kato" println(e.name) // Kato 追記： 上記のようなコードは以下と同じ意味なので、こちらのほうが短くてわかりやすいので適切。 class Employee(var name : String) Employeeのnameはpublicなフィールドですね。*1 nameフィールドには大文字
ScalaのシングルトンをJavaの視点で読み解く - じゅんいち☆かとうの技術日誌
Scalaでシングルトンといえば、object型でしょう。実は、「はい それで終わり」ではありません。今日はそんな話。 object Singleton { println("Construct") val name = "SINGLETON" } println(Singleton.name) jadるとこんな感じ。 public final class Singleton$ implements ScalaObject { private final String name = "SINGLETON"; public String name() { return name; } public static final Singleton$ MODULE$ = this; static { new Singleton$(); } // 上記は public static final Si
シングルトンパターンの遅延初期化をスレッドセーフにするには - じゅんいち☆かとうの技術日誌
前回、前々回と割とヘビーな仕様の話だったので、今回は若干実用的なネタとして、シングルトンパターンの遅延初期化をメモリモデルの視点から、どのようにすればスレッドセーフになるか考えてみたいと思います。 そのシングルトンの遅延初期化はスレッドセーフか 以下のようなシングルトンパターンは日常的に使うデザインパターンの一つだと思います。 ただ、今回はSingletonクラスのgetInstanceメソッドに、わざとロックを掛けずに実装してみました。この場合にどういうことが起こりうるか考えてみたいと思います。 public class Singleton { private static Singleton instance; public static Singleton getInstance() { // バリアがない if (instance == null) { // Normal Load
生成だけではなく複製もファクトリに任せたほうがよい - かとじゅんの技術日誌
DDDで設計を始めると不変条件を維持するために、エンティティなどの可変オブジェクトの複製を行うことがよくあります。 Javaの場合は、Cloneableインターフェイスを実装して、実装型に応じた複製インスタンスを返すcloneメソッドを作る。以下のような感じ。 public class Employee implements Cloneable { private String name; // setter, getter 省略 @Override public Employee clone() { try{ return (Employee)super.clone(); } catch (CloneNotSupportedException e){ throw new Error(e); } } } このcloneメソッドは便利なので普通に使っていたのですが、最近、簡単に使ってよいのだ
マルチコア時代に備えて本気でメモリモデルを理解しておこう - メモリバリア編 - - じゅんいち☆かとうの技術日誌
このエントリを読む前提条件として、マルチコア時代に備えて本気でメモリモデルを理解しておこう - リオーダー & finalフィールド 編 - - じゅんいち☆かとうの技術日誌を読んで、リオーダーとは何かを理解していることとします。 前回のおさらいをすると、 プログラムの実行順序は、リオーダーが許可される場合と禁止される場合がある。並行処理ではリオーダーを想定しなければ、処理結果の整合性が確保できない。(特にマルチプロセッサ環境) リオーダーを禁止して、可視性を保証する。(finalフィールドはコンストラクト時に完全に初期化され、コンストラクト後はスレッドから見えるようになる) でした。 リオーダーについて理解できたら、今度はメモリバリア命令でスレッド毎に扱うメモリと、大域のメインメモリとのメモリI/Oについて見ていきたいと思います。メモリバリアが理解できれば、以下のソース*1のスレッドがな
マルチコア時代に備えて本気でメモリモデルを理解しておこう - リオーダー & finalフィールド 編 - - かとじゅんの技術日誌
長い文章になってしまったので、概要だけ先に書きます。 以下のJavaプログラムは、常に上から下に順番に命令が実行されると思いますか？つまり、aに1が格納された後に、bに2が格納されると思いますか？ 実は場合によってはこの実行順序が入れ替わる場合があります。これはJavaの言語仕様として定義されていることです。これを考慮しないと信頼性のある並行処理は実装できません。 気になる人は以下を読んでみてください。 a = 1; b = 2; すでにインターネットは社会インフラ化しています。ソーシャルネットワークで多くの人とコミュケーションやコラボレーションできる時代で、個人が情報を作り消費することは当たり前になってきています。そして、インターネット上のコンテンツは増加の一途を辿っています。「情報爆発」なんて言葉も耳慣れた言葉になりましたが、その問題解決のためにMapReduceなどの分散処理技術に注
並行処理プログラミングを究めるシリーズの書 - かとじゅんの技術日誌
並行処理プログラミングを究めるシリーズの書 とりあえず以下を読んでます。他に何かよいのがあれば教えてください。 Java言語仕様 第3版 (The Java Series) 作者: ジェームズゴスリン,ガイスティール,ビルジョイ,ギッラードブラーハ,James Gosling,Guy Steele,Bill Joy,Gilad Bracha,村上雅章出版社/メーカー: ピアソンエデュケーション発売日: 2006/12メディア: 単行本購入: 1人 クリック: 108回この商品を含むブログ (42件) を見る The Java Language Specification The Java Language Specification - Threads and Locks Java並行処理プログラミング ―その「基盤」と「最新API」を究める― 作者: Brian Goetz,Joshua
Stringの連結はそう簡単なものではない - かとじゅんの技術日誌
追記： 指摘の通りで、現実的な連結回数での計測でもないですし、統計手法を用いた分析をしていないので、このエントリの計測値は当てにしないでください。なので以下のブログを参考にしてください。 currentTimeMillis()で計測しておいて plusTime:14780, concatTime:7053, sbuilderTime:7, sbufferTime:13 とか、その7とか13の有効数字はいくつだっての。 激しく今更感があるタイトルですが(；・∀・) 昔に取り上げたのですが、 文字列の結合をやるからといって、すぐにStringの+をつかってはいけない - じゅんいち☆かとうの技術日誌 Stringの+演算子は間違った使い方するとパフォーマンスが低下しますよっていう話題。若干ネタ成分ありますが、ご容赦ください。 これ系の話題は自分的にはオワコンなんですが、最近、また話題を見つけた
並行処理におけるメモリの可視性保証について - かとじゅんの技術日誌
並行処理プログラミングにおいてJavaのメモリモデルを深く掘り下げたことがなかったのでちょっと本気出してみます。しかし、間違っているところあるかもしれません。ツッコミいただければ適宜訂正させていただきます。 可変データへのアクセスを同期化 JavaでActorっぽいものを作ってみるで使っていた、canceledフラグはvolatileという修飾子を付けて宣言しています。 簡単にいうとと固有ロックを使わずに、フィールドを読み込むスレッドが、最後に書きこまれた値を見えるようにするためのvolatile修飾子です。 と、あまりに簡単に説明しているので、もう少し具体的に理解するために、まず、volatile修飾子を付けない通常の変数では、どうなるのかEffective Java第二版の「項目66 共有された可変データへのアクセスを同期する」の例で考えてみたいと思います。 Effective Jav
ビジネスモデリングで考えること ー基礎編ー - かとじゅんの技術日誌
DDDとかの抽象度の高い話はなかなか分かりずらいという方もいると思うので、以下の書籍で扱っているビジネスパターンでのモデリングも併せて考えていきたいと思います。 私もまだ勉強不足というものあるし、チャレンジングな試みなので途中でヘタれるかもしれませんが、、、頑張りたいと思います。お付き合いいただければ幸いです ビジネスパターンによるモデル駆動設計 作者: Pavel Hruby,依田智夫,溝口真理子,依田光江出版社/メーカー: 日経BPソフトプレス発売日: 2007/08/13メディア: 単行本 クリック: 7回この商品を含むブログ (14件) を見る 登場人物 とりあえず、今回は登場人物だけ把握しましょう。 まず、本書で主軸に掲げているREAとはなんでしょうか。 REA = Resource, Event, Agentの略で、本書では経済リソース、経済イベント、経済エージェントと表現して
JavaでActorっぽいものを作ってみる - かとじゅんの技術日誌
前回 JavaでScalaの"アクターのようなもの"を作ろうということだったので、早速 作ってみました。目的は、Actorの概念に触れることで、並行処理プログラミングの勘所を学ぶことなので、その前提で読んでいただければと思います。 リソース共有モデルには限界がある 「オブジェクト指向プログラマが次に読む本 Scalaで学ぶ関数脳入門」には、複数のスレッド間でリソースを共有する「リソース共有モデル」の限界について触れています。 「リソース共有」モデルを前提としている限り、プログラムの規模が大きくなるに従って、並行処理にまつわる複雑さや問題に対処することが困難になってきます。 これに対して、もしスレッド間で同一リソースを共有しないで、協調処理を行うとしたらどうでしょうか。リソースを共有しなければ、データ不整合やデッドロックなどの、並行処理で問題とされていることを回避できるのです。メッセージパッ
タスクを並行で実行するために必要なこと 〜基礎編〜 - かとじゅんの技術日誌
スレッドセーフの話も語ればキリがないのですが、そろそろ「タスクを並行に実行する」話題にいってみましょう。この手の記事は結構あるし、書籍の内容をまるまるというわけにいかないので、独断と偏見でポイントを絞って軽く解説する感じで書いてみます。とりあえず、ThreadクラスとExecutorクラスあたりから。 この書籍のP129あたりです。 Java並行処理プログラミング ―その「基盤」と「最新API」を究める― 作者: Brian Goetz,Joshua Bloch,Doug Lea出版社/メーカー: ソフトバンククリエイティブ発売日: 2006/11/22メディア: 単行本購入: 24人 クリック: 419回この商品を含むブログ (163件) を見る 並行処理のアプリケーションには、「良いスループット」と「良い応答性」の両方が必要と書かれています。スループットは、単位時間あたりの処理能力のこ
スレッドセーフにするために考えること 〜応用編 その3〜 - かとじゅんの技術日誌
終わったかとみえたスレッドセーフのネタですが、再浮上。 連投ものだと読むのが大変なんですが、よくぞこのエントリまでおいでくださいましたm(__)m ということこで、Departmentクラスはバリューオブジェクト(不変オブジェクト)でしたが、エンティティ(可変オブジェクト)にしてみたら、どういう苦労をするのだろうか、というMっ気ったぷりな今回のテーマ。 早速、Departmentクラスをエンティティにしてみました。nameは可変できる属性。AbstractEntityはこちら参照 public class Department extends AbstractEntity { public static Department of(UUID id, String name) { return new Department(id, name); } private String name;
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Error, Defect, Fault, Failureの定義と解釈 - かとじゅんの技術日誌
