情報更新

last update 10/22 14:09

ツイート検索

 

@j5ik2o
サイトメニュー
Twilogユーザー検索

Twilog

 

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

Stats Twitter歴
4,297日(2008/01/17より)
ツイート数
35,487(8.2件/日)

ツイートの並び順 :

表示するツイート :

2019年10月22日(火)3 tweetssource

2019年10月21日(月)16 tweetssource

10月21日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

つまるところ、組織の戦略は上位と下位で入れ子構造、ある意味モジュールのようになって整合性がないと機能しないはずなんだよな。組織に明示的な階層がない、カニバる組織もあるけど、同じ陣営の組織同士なら戦略の整合性は一致しなければならないと思う

posted at 17:50:36

10月21日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

コンテキストの戦略が部分最適になって全体最適と相反するみたいな話は、戦略のベクトルがあってないからそうなるではないかな。OKRのように戦略がピラミッドストラクチャーに沿っていて、個人や組織が目標を達成することで全体の目標をクリアできるように設計すればいいと思う

posted at 17:50:33

10月21日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

コミュニティの中で倫理的か否かは相対的に決まると思うので、雇う側が一般から外れていると外れた人が採用できる。変態と天才がいる会社で働いてたけど朝会は16時からやってたこともある。つよつよかはさておき、結局自分たちの倫理のクラスターに近いかどうかが優先されるということでしょうね

posted at 17:26:22

10月21日

@t_tonchim

狩人とんちむ@t_tonchim

「つよつよエンジニアだったら倫理的に問題あっても雇うでしょ」って認識の人を見かけてあー…ってなってる。

つよつよだろうがよわよわだろうが一緒に働きたくないから雇うわけないじゃない、会社やチームにマッチするかどうかの方が大事だよ

Retweeted by かとじゅん@冰気錬成

retweeted at 17:24:21

10月21日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

1チームに複数の責任を持たせるのはリソースが分散するのでマッチング数を増やすことに価値があるなら、そのための境界づけられたコンテキストを作ることを提案するかな。周りのコンテキストには支援してもらう。個々のチームが目標をクリアすることで全体の目標をクリアしたいよね twitter.com/little_hand_s/

posted at 16:38:12

10月21日

@zenzengood

神崎 善司@zenzengood

明日の「RDRA WorkShop !!」ご参加の皆さん。
演習は自分の作りたいシステムのモデル化なのでシステムのイメージを膨らませておいてください
作りたいものがない場合はアマゾンなどを参考にします
やりたいことを箇条書きで洗い出しておくと演習はスムーズに進むと思います。
phper-oop.connpass.com/event/149529/

Retweeted by かとじゅん@冰気錬成

retweeted at 16:28:11

10月21日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

Lean Architectureの巻末にあるScalaのDCIサンプルがmutableでクソなので、イミュータブルで書き換えようとしている。めちゃくちゃ複雑になりそうというか、実装できそうにないのでは…

posted at 16:26:57

2019年10月20日(日)15 tweetssource

10月20日

@sugimoto_kei

杉本啓@sugimoto_kei

アーキテクチャは非機能要件に応える設計、という考え方は誰が始めたんだろう(RUPはそんな言い方だったと思うが)。ブルックスの「人月の神話」も、ケント・ベックのXPも、ジム・コプリエンのリーン・アーキテクチャも、もっとドメインに根ざした構造を、アーキテクチャと呼んでいる。

Retweeted by かとじゅん@冰気錬成

retweeted at 13:58:18

10月20日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

オライリーのMSA本に登場する「共有モデル」もデザイン・ルールに、「隠れモデル」は隠されたデザイン・パラメータに対応する。モジュールの特性を分かっていればシンプルに理解できる。というか、50年来この手の話は変わってない…。

posted at 12:03:30

10月20日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

一般的なモジュール論とオブジェクト指向の共通点は、デザイン・ルールにインターフェースを、デザイン・パラメータはカプセル化によって保護するというあたり。知識と労力を分離するのは共通する。動的束縛もデザイン・ルールに含まれる概念だが、ソフトウェアならではの特性かなと

posted at 11:52:28

10月20日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

メイヤー氏曰く"クラスはオブジェクト指向ソフトウェア構築において、モジュール化と型システム両者の基盤を与えるものである”モジュール化にとって中心的な役割を果たすのはクラス。クラスはオブジェクトの型だけではなくモジュールの単位でもある。クラスがないとモジュール構造も作れない

posted at 11:43:50

10月20日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

ある程度複雑なシステムは複数の部品(モジュール)に分割する。この分割が適切なら変化に対応できる。たとえば、共通の結合ルールに従えばよりよいモジュールに置換えたり、モジュール内の情報は外部から隠されているので改変が他のモジュールに影響しない。

posted at 10:19:03

10月20日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

qiita.com/crossroad0201/
この記事もDCIのロールに関連する話題。ただ、「担当者がタスクをクローズする」の担当者はユースケースのアクターなのでシステムの外にいるので、これはドメインモデルではないのではと思いますけどね。この観点で分析するとすべての振る舞いは人に密結合する気がする

posted at 09:57:50

2019年10月19日(土)12 tweetssource

10月19日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

コンテキスト依存のビジネスロジックを、コンテキストに中立なモデルに無理矢理押し付けたり、モデルへの割り当てを回避するかわりにドメインサービスの濫用で手続き化したりすることで、メンタルモデルを台無しにするはあるなー。コプリエンさんの主張が少し理解できたが、さて仕事にどういかすか

posted at 22:39:15

10月19日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

ドメイン・フレームワークはYAGNI思考で考えると実際に困ってからでよいのでは?という意見あると思う。正しい。けど、こういった基盤を用いることで設計のレバレッジを効かせられるは別の課題。これらは直交する変数だから同時に考える必要があると思う

posted at 21:57:50

10月19日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

マルチパラダイムデザインの立場からみると、この記事中の分析モデルに基づくドメインフレームワークは共通性分析の結果に対応すると思います

posted at 21:30:47

10月19日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

@cactaceae コンテキスト依存のロジックだけをロールに定義するが正しいですね。コンテキスト非依存な振る舞いは今までどおりデータを表現するモデルに定義することになると思います

posted at 12:13:18

10月19日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

安定と変化の構造を作り出すのがアーキテクチャで、それを理解しないでDCIの単なるコンテキスト依存のメソッドバインディング機能だけを理解しようするもアンチパターンだな。いやまぁ入口としてはそれでいいけど出口とは違う

posted at 12:05:23

2019年10月18日(金)28 tweetssource

10月18日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

少人数なら、居酒屋で勉強会するのではなく、会議室で飲み会したほうがよいのではと思っている。ホワイトボードもプロジェクタも心配ないし。

posted at 18:22:04

10月18日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

かとじゅんさんのTLが難しくてわかりませんと言われているが、年末の「すえなみチャンス忘年会」にきたらわかるかな。いや余計に混乱するかも知れないが…。

posted at 18:12:16

10月18日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

@minaraiengineer コンテキストに依存しない操作やルールはデータクラスにあるべきですね。コンテキスト依存のビジネスロジックはロールクラスに定義。実行時のコンテキストごとにそれらを合成する、感じだと思います

posted at 17:51:31

10月18日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

DCIの観点がない状況でどういう設計をしているのか(自問) コンテキストに依存するような振る舞いはドメインサービスにいきそうな気がするな。えっ、預金口座が振込元/振込先になるはずが、送金サービスと預金口座だけになり、動的な側面が欠落されてないですか…。そゆことか!

posted at 17:44:02

10月18日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

とにかくメソッドを追加or継承で分割はリスクありますよ。そこにコンテキストは考慮されていますか?関心事の分離はコンテキストを無視できないですよね?という話か。たとえば”とにかくメソッドで肥満症モデル(笑)”をDCIで解消できそうだな

posted at 17:36:04

10月18日

@sugimoto_kei

杉本啓@sugimoto_kei

@j5ik2o そうですね。預金口座が振込元か振込先はコンテキスト依存なので、振込元/振込先に帰属するロジックは預金口座に持たせるのではなく、事後的に注入しようという考えですね。オブジェクトが静的に分類される(それに応じて振る舞いも決まる)という古典的カテゴリー論から離れているわけです。

Retweeted by かとじゅん@冰気錬成

retweeted at 15:39:04

10月18日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

継承で差分プログラミングは80年代ごろに敬遠されているし、安易にサブ型で設計の共通性や可変性を台無しにしないようにするには、DCIの視点は有益。なるほど。だんたんわかってきた。

posted at 15:24:49

10月18日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

預金口座に対して、振込というコンテキストで、振込元口座・振込先口座という概念が登場したらどうするか。預金口座のサブ型としてそれぞれを作る…。コンテキスト増えたらまたサブ型増やす?ロールで表現されるべきがクラス継承という形で共通性と可変性がごちゃごちゃにされてしまう。という話だな。

posted at 15:15:02

10月18日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

DCIでは、ドメインオブジェクトはロールを表現するロジックを持つ。ただしコンテキストなしでは存在しない。ロールで利用されるデータもオブジェクトだがコンテキストと直接関係ないデータ操作に関する責任を負う。が利用時は一体化される。

posted at 11:15:02

10月18日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

「預金口座が振替処理においては振り込み元口座というロールを演じる」これがデータとロールの違い。データロジックとロールロジック(ビジネスロジック)を分離しつつ利用時は合成されなければならない。メンタルモデルがそうだからってことかな。

posted at 11:01:40

10月18日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

ロールの選択はコンテキストに依存する。口座間送金コンテキストでは、送金ロールが選択可能で、送金ロールには預金口座データにバインドできなければならない。という理解であってるかな。

posted at 09:54:31

10月18日

@j5ik2o

かとじゅん@冰気錬成@j5ik2o

DCIのデータを単なる構造体とみるかいなかで、貧血症に繋がるかが決まる気がする。僕は単なる構造体ではない、 と思っていて、データに対する操作や不変条件の保護は含まれると思う。操作をしても残高はゼロにならないなど。そうでなければ共通性の安定した基盤になれないから。

posted at 09:50:46

このページの先頭へ