elscreen-tab をupdateしてみた
実はEmacsはタダのtodo list 程度にしか使用してないのだけど、 MacだとUIにbugがあり、elscreen由来のパフォーマンスの問題があったのでupdateしておいた github.com
Emacs27のtab 昨日は (tab bar, tab line) はいまいち使い勝手が不明で、Macでは正しく動かないように見えるので、需要としては 若干elscreen-tabの方が高いはず。
elscreen.el がtabを9個ぐらいまでしかサポートしていないとか、パフォーマンスの問題があるから、若干そこがネックではある。
"「実践ドメイン駆動設計」から学ぶDDDの実装入門" (全14章) 総評
- 想定通りの読みやすさの本であった
- DDD について興味はあるものの予算も時間も気力もないという方に対する取っ掛かりになりそう。
- 自分の中で解釈が正しくなかったりしたDDDに対する知見を比較的短時間で補正できたと思う。
- 呼んでピンとこない部分はネットで調べればそれなりに情報が出てくるので調べることで理解が深まったと思う。
全章がおそらく IDDDの章と1対1対応 なので補助資料として良さそう。
- 逆にDDDについて知識０で読み始めたりプロダクションでシステムを作ってない人には薄くて読んでも効果ないかも。
初回の見積もりの読了所要時間が頑張れば３時間だったはずが、ブログ用にメモをしていたり調べたりして３０時間位かかっていたかも、、、
- ひとえに集中力の衰え、、、
"「実践ドメイン駆動設計」から学ぶDDDの実装入門" 14 章感想 (全14章)
"「実践ドメイン駆動設計」から学ぶDDDの実装入門"
「実践ドメイン駆動設計」から学ぶDDDの実装入門 (CodeZine Digital First)
- 作者: 青木淳夫,山田祥寛
- 出版社/メーカー: 翔泳社
- 発売日: 2019/05/31
- メディア: オンデマンド (ペーパーバック)
- この商品を含むブログを見る
「アプリケーション」〜ドメインモデルを利用するクライアント〜
気になった所
- p168 図１４．３「
DataPayload Object」ではなくてDomainPayload Object ?
memo
application層からUI層（プレゼンテーション層）へのデータの渡し方
1. DTO: 複数のAggregatesをDTO Assemblerを用いてDTOへ値を詰める(Domain objectをUIへは非公開にできる)
- クライアントのタイプごとにDTOを用意するのでドメインモデルに影響がない
1. DPO: 複数の集約を参照し、UI層までデータを公開する
1. ユースケースに最適化したクエリをレポジトリで用意し、値オブジェクトで返す。（値オブジェクトはあくまでも業務ドメインに特化した物であること。）
- 値オブジェクトに入れて変更できないようにした状態で公開しているのが味噌なのか？
p.172 ↑ IDDD本では好みや最終目標のトレードオフで選ぶことを推奨しています。 とあって元も子もない、、、
"「実践ドメイン駆動設計」から学ぶDDDの実装入門" 13 章感想 (全14章)
"「実践ドメイン駆動設計」から学ぶDDDの実装入門"
「実践ドメイン駆動設計」から学ぶDDDの実装入門 (CodeZine Digital First)
- 作者: 青木淳夫,山田祥寛
- 出版社/メーカー: 翔泳社
- 発売日: 2019/05/31
- メディア: オンデマンド (ペーパーバック)
- この商品を含むブログを見る
「境界付けられたコンテキストの統合」〜分散システム設計〜
- 境界付けられたコンテキストで分けられたシステム間の連携についてアーキテクチャの概要例が記載されている。
- MIMEタイプはなくても良さそうだが使う意義がわからなかった。
- 概要はわかった気がするが、どう実装するかはIDDDのサンプルコードで勉強する必要がありそう。
気になった所
- p158脚注のミスプリント
"「実践ドメイン駆動設計」から学ぶDDDの実装入門" 12 章感想 (全14章)
"「実践ドメイン駆動設計」から学ぶDDDの実装入門"
「実践ドメイン駆動設計」から学ぶDDDの実装入門 (CodeZine Digital First)
- 作者: 青木淳夫,山田祥寛
- 出版社/メーカー: 翔泳社
- 発売日: 2019/05/31
- メディア: オンデマンド (ペーパーバック)
- この商品を含むブログを見る
「リポジトリ」〜集約の永続化管理を担当〜
memo
- 「コレクションが、メモリ上にあると錯覚させることができるようにすること」
- 「集約に対してのみ、リポジトリを提供すること」
- 集約とリポジトリのインタフェースはドメイン層に、リポジトリの実装クラスはインフラストラクチャ層に配置（DIPに従う。つまり、ドメイン層へ影響のない実装の切り替えを容易にする。）
- リポジトリ設計
- コレクション指向：集約の登録時に、Add method。RDBを使用?
- 格納がレコード単位が味噌？
- 永続指向：集約の作成変更時に、Save method （差分変更ではなく、集約全体を一括更新）。KVSを使用？ (IDDDではキーとして「境界付けられたコンテキストの短縮名、集約の名前、一意な識別子」の組み合わせを提案)
- 格納が集約全体というのが味噌？
- コレクション指向：集約の登録時に、Add method。RDBを使用?
"「実践ドメイン駆動設計」から学ぶDDDの実装入門" 11 章感想 (全14章)
"「実践ドメイン駆動設計」から学ぶDDDの実装入門"
「実践ドメイン駆動設計」から学ぶDDDの実装入門 (CodeZine Digital First)
- 作者: 青木淳夫,山田祥寛
- 出版社/メーカー: 翔泳社
- 発売日: 2019/05/31
- メディア: オンデマンド (ペーパーバック)
- この商品を含むブログを見る
「ファクトリ」〜複雑な生成をユビキタス言語でシンプルに〜
気になった所
memo
- DDDにおけるファクトリは「ユビキタス言語を用いて集約をシンプルに生成する」ことに重きがある。
- 集約ルートにて、別のオブジェクト（主に集約）を生成。このとき、集約のプロパティを使用して良い。
- サービスにて、別の「境界付けられたコンテキスト」のオブジェクトを、ローカルの「境界付けられたコンテキスト」の別のオブジェクトに変換して生成
分からないこと
優れたファクトリは「生成される具象クラスではなく、要求される型に応じて抽象化されないといけない」
