技術書典5にサークルとして参加します。 - pospomeのプログラミング日記
技術書典5にサークルとして参加することになったので、 書籍の詳細についてまとめました。 techbookfest.org [追記] BOOTHから購入できるようにしました。 pospome.hatenablog.com 書籍のざっくり情報は以下です。 書籍の目次はこちら サーバサイドのアプリケーションアーキテクチャに関する書籍 ページ数は155ページ PDF版のみ 価格は1冊1000円 購入していただけるとその場でQRコードが印刷されている紙を渡すので、そこからPDFをDLしてください。 サンプルコードはGo言語ですが、サーバサイドのアプリケーションアーキテクチャがメインなのでサーバサイドのアプリケーションエンジニアであればGo言語に関わらず役に立つはず かんたん後払いには対応していません 当日まで可能な限り内容を精査するので、内容が一部変更されるかもしれません。 当日は見本誌を用意するの
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える - pospomeのプログラミング日記
devfest 2017 tokyo の発表資料です。 Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える from pospome 当日は入室できない人もいたらしい & 機材トラブルで10minほど開始が遅れてしまった ということで申し訳なく思っています。 また、立ち見する価値がある内容を提供できたのだろうか? とも思っています。 スライドは単体でも発表内容が伝わるように文章を多めに載せているので、 是非確認してみてください。 100ページ越えていますが・・・。 #DevFest_room2 入れなかった。。— t.junichi (@tjun1) 2017年10月9日 ものすごい立ち見人数 #Devfest17 #DevFest_room2— バトルプログラマー柴田智也@少女終末旅行 (@tomoya_shibata) 2017年10月9日 ルーム2これから並ぶ方はま
DDDにおいて、なぜ複数の集約にまたがってトランザクションをかけてはいけないのか（multiple aggregates in one transaction） - pospomeのプログラミング日記
DDDでは 集約 = トランザクション境界 でなければならないので、 複数の集約をまたがるデータの永続化処理は結果整合性になる。 なぜ集約をまたいでトランザクションをかけてはいけないのかというと、 集約で「データの一貫性の境界」を表現するため。 なので、集約同士はデータの一貫性を保証しない = 結果整合性 ということになる。 集約がトランザクション境界ではない場合はどうなるのかというと、「データの一貫性の境界」がドメインレイヤで表現できなくなる。 あるときは 集約A, 集約B が一緒のトランザクションで登録され、 あるときは 集約A, 集約B, 集約C が一緒のトランザクションで登録される、というケースがあると、 「データの一貫性の境界」はアプリケーションレイヤのトランザクション開始から終了までのコードで表現されてしまうので、 それぞれの集約がどの粒度で一貫性を保たれるのかが分からなくなる
DDDにおいてリポジトリとDBのトランザクションは切り離せないのか? - pospomeのプログラミング日記
DDDではリポジトリに対してDIPを利用し、インターフェースと実装を切り離す傾向にある。 これはいわゆる「抽象に依存せよ」ってやつなので、 DDDというよりは既存のプログラミングテクニックになる。 で、これを実現するためにリポジトリを以下のようにインターフェースで実装する。 コードはTypeScriptです。 interface UserRepo { insert(user: User, master: DbMasterConnection): Promise<User>; findByName(name: string, con: DbConnection): Promise<User>; findById(id: number, con: DbConnection): Promise<User>; }リポジトリの実装自体はインフラレイヤに置く。 「データを取得する」ということなので、個
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
