並び順は適当だけど、後ろに行くほど少し分野違いや読むのが難しい系統。
チームで複雑なJavaScript/Reactアプリを作る前の設計の話。 アーキテクチャに悩んでいる間も実装はコンポーネント思考であるなら並行して進めやすいという話。
Almin.jsは作りながら設計したという話。
DDD本の中では一番読みやすくためになることが多い。 アーキテクトの話なども参考になる。 またDDDの文脈で出てくるモデルやリポジトリなどは、人によって言ってることが違うという事実をちゃんと注記してくれている。 CQRSについてはこの本を読むとよい。
DDDについて分かりやすく書かれてる書籍。 DDD本/IDDD本が分かりにくいところを分かりやすく書こうとした感じのする内容。 DDDに興味がある人は読むとよい感じな気がする。
ユースケースという言葉や役割についてはこの本の影響を受けている。 DDDはオブジェクト指向の発展形のように見える。
CQRSはイベントソーシングが必須ではない。CQRSっぽい実装はすぐにでも初められる。 Repositoryを介さないで、直接DAOから、Read Modelを構築してそのまま返すのもあり
CQRSの小さな実装例。
MVVMにおけるViewModelについて Store/StateはViewModelとかなり近いものになっていくのではという文脈で調べていた。
ViewのためのStoreとDomainのためのStoreという考え方について。
クリーンアーキテクチャの訳。
データの流れについて確認するときに見てた。
クリーンアーキテクチャを目指そうとして、Input/Outputのところをどうしようと悩んでいるときに見ていた気がする。
依存関係逆転の原則(DIP)について分かりやすい解説。
CSSは賢く書かないという影響を受けた。 そのためCSSは最低限の拡張をPostCSSでやるようにしてる。
CSSのstateの考え方について参考にした。 SUIT CSSのルールはしばらく使ってるけど、一番シンプルでReactと相性がいいと思ってる。 コンポーネント志向である場合に相性がいいルールを持ってる。
.is-stateをファイルとして切り出すのはオリジナルルール。
とにかくCSSはステートを増やしたくないため、常に一覧できるようにするためのルールとして入れた。
will-changeなどでステートを切り替わることを明示できるので、ファイルとして切り出されてるのと意味論的によい感じになった。
コンポーネント志向でCSSを書いた場合に、親から子へ影響を出したいという場合にどうするかを考えていた。 コンポーネントでコンポーネントとして外から触れるものを変数として定義して、外からそれを定義し直すことでできそうという話。 現実的にはネイティブなCSS変数じゃないとスコープが実現できないので現時点では諦めていた。
Atomic DesignをやるとCSSの詳細度が一定になるという話。 SUIT CSSとは異なるルールだけど、コンポーネントを考えると大体そうなる。
Androidでの話。
こちらもAndroidの話。
トランザクションスクリプトとドメインモデルについて。
ステートソーシングとイベントソーシングについて。 イベントソーシングはまだ上手くやれるイメージがなかったのでステートソーシングで考えている。
karen-irc/karen: This is the forked project from https://github.com/erming/shout
レイヤードアーキテクチャについて。 Drivers › Cycle.jsも見るといいかもしれない。
CQRS + ESの話として。
DDDはパターン集であるという話。
いわゆるIDDD本。
DDD、CQRS、ES。
いわゆるDDD本。
POEAA。 DDD本の後に読んだけど、DDDはやっぱりこの辺とベースとなる部分は同じ所が多いという感じになった。
情報設計(IA)についてかなり分かりやすい本。
構造化の考え方として分類法は次の2つになるという話。
- 並列的構造
- 階層的構造
これは、まさにドメインでは階層的になっていき、Store/Stateでは並列的にするという構造化がおきた。 このIAという分野もパターン・ランゲージから来ていると感じる部分があった。
IAという言葉もやはり変化していると思って探して見つけた記憶。
企業システムのアーキテクチャの話として見た。
今ある色々なアーキテクチャの源流的なものを巡っていて、パタン・ランゲージ―環境設計の手引を探しているときに見た。
DDDもパターン集であるため、この源流はやはりこの辺にあるのではと思って調べていた。 IAの話もそうだけど、構造化の考え方などは都市構造の考えの話とも一致している感じがする。
「何を」作るのかを支援するというもの、抽象的な形で提供される
パターンはデザインを支援する。良いデザインは問題を解決する
パターンランゲージは言葉で形を表すので、それは誰に取っても同じ形にならないとおかしい
真偽値を科学的なものじゃない、コードとかにも「良い悪い」という適用したのがパターンの面白いところ
via http://twilog.org/azu_re/date-160519
パターン・ランゲージのアレグザンダーは1970年代にはコンピュータによるデザイン設計を試みてたという話があった。 建築的にはアルゴリズミック・デザインの源流となる考え方で、それを調べてた。 また1970年代ではまだコンピュータの性能などもあって諦めた部分があって、それの代わりにパターンの流れがあった。
Large-scale JavaScript Application Architecture // Speaker Deck
このリポジトリのタイトルの元ネタ。
公開初期はSource Mapによるソースコードが読めたので参考になった。
コンポーネントのproject/ディレクトリの元ネタ。