アーキテクチャについて知ってみる 「ゆらぎのある決定」以降のまとめ #DevKan #devlove
- kamatamadai
- 3383
- 0
- 1
- 2
バリューストリームの例として「デプロイメントパイプライン」が分かりやすい。継続的デリバリを参照のこと #DevKan #ステマ
2014-12-20 16:12:14デプロイメントパイプラインだけではなく、それを取り巻く人の動きも重要。どんな人がその成果物にアクセスするのかは事前に定義する必要がある。どんな人がいつ何をするのかは先に決めるべき。 #DevKan
2014-12-20 16:13:31スクラムはバリューストリームのフレームワーク。#DevKan
2014-12-20 16:13:59Vision→ProductBacklog→SprintBacklog→2-4WeekSprint→Potentially Shippable Product Increment
2014-12-20 16:15:13スクラムのプロセスもバリューストリームと捉えることができる。スクラムを開発者だけで回そうと思っても、プロダクトバックロブが書けない。それはプロダクトバックロブにビジネス価値を投影するような仕組みを事前に定義しておかないと行けない #DevKan
2014-12-20 16:16:22#DevKan ソフトウェアアーキテクチャはドメインのパラダイムと無関係ではいられない。
2014-12-20 16:19:37「ソフトウェアアーキテクチャはドメインのパラダイムと無関係でいられない」ドメインが求める機能をうまく表現するようなアーキテクチャ選択を行う必要がある #DevKan
2014-12-20 16:20:21ソフトウェアアーキテクチャの境界はドメインの境界に従う #DevKan
2014-12-20 16:20:41「ドメインの表現方法(モデル化するためのツール)と、そのドメインを実装するためのアーキテクチャは無関係にいられない」 すごいわかる。#DevKan
2014-12-20 16:21:09そうなんだ。チーム構成までもがドメインに従うのか。 RT @mitsugeek: チームの構成はドメインの構成に従う #DevKan
2014-12-20 16:23:16@kawakawa トランザクションスクリプトの開発はオフショア、ルールエンジンなどの複雑なものは顧客に近い所。ドメインの複雑度は開発者の能力に・・・
2014-12-20 16:24:56「チームの構成はドメインの構成に従う」例えば、報告書の画面自体はトランザクションスクリプト + SQLテンプレートでサクサクかけるので、オフショアに出してもリスクは少ない。権限周りのコア部分はリスク高いで自社開発する、など。 #DevKan
2014-12-20 16:23:03ソフトウェアアーキテクチャはチームのスキルに制限される。 #DevKan
2014-12-20 16:26:16「ソフトウェアアーキテクチャはチームのスキルに制限される」DDDで開発するときに、技術的に若いエンジニアに振るのはおそらく問題。また同じアーキテクチャを採用するチームは近くにいたほうがいい。チームの構成とアーキテクチャ構造も関わりが深い #DevKan
2014-12-20 16:27:22「ドメインの変化の速度によって、基本設計書の書く単位もかわる」 これはちょっと響いだ。確かに。結果そうなるかもしれないけど、変更コストを含め意識したことはなかった。 #DevKan
2014-12-20 16:27:34