自分は iota の使い所が分からなかった。 なんか事故りそうだし、明示的に値を宣言した方が分かりやすいような気がする。 で、こんなツイートをしたら・・・ #golang の iota 使った定数定義って、定数の並び順によって値が変わるから、なんか事故りやすい印象あるんだよな。誤って順番変えちゃいました的な。みんな使ってるのかな。iota 使わなくても設定する値を間違えたら結局事故るから、あまり気にしなくてもいーのかな。— pospome (@pospome) 2017年8月19日 tenntenn さんと kaneshin0120 さんに返信をいただいた。 DBに保存するような値は基本使ってないですね— tenntennʕ ◔ϖ◔ʔ ==Go (@tenntenn) 2017年8月19日 なるほど。理由としては「永続化される値だと事故るとデータの修正が発生して面倒」だからでしょうか? 個

ドメイン駆動設計 #1 Advent Calendar 2018の14日目を担当する@pospomeです。 今回はDDDとコードとしての正しさについて書いてみようと思います。 DDDは設計手法である コードとしての正しさ コードとしての正しさを見失う ユースケースの日本語を"そのまま"コードに落とし込もうとする 無駄にオブジェクト同士の結合度を上げる RubyのActiveRecordの正しさ コードとしてのメリット、デメリットを具体的に考えて解決する まとめ DDDは設計手法である DDD = ドメイン駆動設計 ですよね。 "設計"という単語が付いていることから分かる通り、DDDはあくまでソフトウェアにおける設計手法です。 そのためDDDの成果物は"コード"であり、DDDの目的は"コードの可読性を上げること"であると自分は考えています。 DDDが持つ"ビジネスを理解する", "ドメインを

Mercari Advent Calendar 2018 の13日目は株式会社メルペイ認証基盤チームの @pospome がお送りします。 メルカリのアドベントカレンダーで特定の実装パターンの網羅集みたいなやつを書こうと思ったんだけど、組み合わせ爆発でまとめきれそうにないな・・・。テーマ変えるか・・・。— pospome (@pospome) 2018年12月4日 実装パターンの網羅集が書けそうにないことに気づいた & 改めて考えると実装パターン自体が破綻している気がするので、 せっかくなら自分が使ったことのない機能を利用してみようかなと思いました。 そこで今回は"テストの並列実行"を使ってみました。 テストを並列実行してみる 現在時刻に依存するテストは失敗してしまう 現在時刻に依存するテストだけ並列化しない 現在時刻を引数に指定するかどうか 引数で現在時刻を指定する場合の実装例 現在時刻

技術書典5にて販売した "pospomeのサーバサイドアーキテクチャ" をBOOTHから購入できるようにしました。 以下から購入できます。 価格は技術書典と同じ1000円です。 booth.pm 技術書典に来てくださった方への特典として価格を少し上げたり、 内容を落としたりしようと思いました。 しかし、遠方のため行けない人がいたり、 予定があって行けない人がいたり、 行きたくても行けない場合もあるので、 特典というのも少し違うかなと思い、価格は据え置き、内容も同じという形で販売しました。 次の技術書典では当日来てくださった方向けの特典でも用意しようかなと思っています。 ちゃんとしたイラストを表紙にした物理本をプレゼントしたり、 一部の内容を落としたりしようかと。 落とす内容は独立して切り離せる内容にしないといけないので、次回はそれも考えて書く必要がありますね。

技術書典5にサークルとして参加することになったので、 書籍の詳細についてまとめました。 techbookfest.org [追記] BOOTHから購入できるようにしました。 pospome.hatenablog.com 書籍のざっくり情報は以下です。 書籍の目次はこちら サーバサイドのアプリケーションアーキテクチャに関する書籍 ページ数は155ページ PDF版のみ 価格は1冊1000円 購入していただけるとその場でQRコードが印刷されている紙を渡すので、そこからPDFをDLしてください。 サンプルコードはGo言語ですが、サーバサイドのアプリケーションアーキテクチャがメインなのでサーバサイドのアプリケーションエンジニアであればGo言語に関わらず役に立つはず かんたん後払いには対応していません 当日まで可能な限り内容を精査するので、内容が一部変更されるかもしれません。 当日は見本誌を用意するの

-----------追記------------- 仕様パターンについては以下の書籍で可能な限り詳しく解説しています。 興味あれば読んでみてください。 pospome.booth.pm -----------追記おわり------------- エリック・エヴァンスのDDD本では「仕様パターン」という実装パターンが説明されている。 仕様上のバリデーションはエンティティや値オブジェクトに実装してはいけない。 複雑な仕様による複雑なバリデーションロジックは クラスの肥大化を招いてしまう。 class User { //こういったバリデーションは肥大化を招く public boolean isXXX(){ //複雑なロジック } } また、こういったバリデーションは複数のエンティティを必要とする場合があるので、 どのクラスの責務とするのかを明確に判断できないこともある。 class User

最近、golang のレイヤ構造において、他のコードに影響なくインフラレイヤのデータソース実装を差し替えることは可能か? という質問を受けた。 回答時間が限られている中で質問を受けたので、 「現実的には難しい」という雑な回答しかできなかった。 さすがに雑すぎるなと思ったので、 自分なりの回答をちゃんと残そうと思う。 影響を受ける対象となるコードは? MySQL -> PostgresSQL への差し替え MySQL -> WebAPI への差し替え インフラレイヤにDB依存のコードをまるっと実装してしまう DDDの場合 独自の接続オブジェクトを作る DDD本 & IDDD本のサンプルはどうなっているか? 差し替える必要はあるのか? まとめ 影響を受ける対象となるコードは?golang のレイヤ構造において、他のコードに影響なくインフラレイヤのデータソース実装を差し替えることは可能か? とい