python の開発環境を準備してみる
↓この辺の記事を参考に
~/.zshrc に
# for anaconda activate/deactivate cmd alias activate="source $HOME/.pyenv/versions/anaconda3-4.1.1/bin/activate" alias deactivate="source $HOME/.pyenv/versions/anaconda3-4.1.1/bin/deactivate"
を設定してちゃんと動くようになった
scala だったらbuild.sbtとかに libraryDependencies でライブラリ指定すればいいだけなのだけれど、pythonはちょっとなんかやり方が違うのね
難しい・・・
- 作者: Bill Lubanovic,斎藤康毅,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2015/12/01
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
第2回DDD座談会に参加してきたメモ
第2回DDD座談会
19:00 - 22:10
ハッシュタグ #dddzk
DDDを実践でやってる人が結構いる
最近のトピック
上坂さん @takashiuesaka
最近はマイクロサービス系の引き合いが多い 境界づけられたコンテキストの話が多い SchooでDDD入門について喋る
増田さん @masuda220
最初はオブジェクト指向の考え方をチームで一緒にするところから オブジェクト指向だけではだめで、分析設計が出来ないと・・・ きれいな答えを早い段階で手に入れたがるが、その必要はない 一番最初のものはだいたい間違っている フィードバックで整理してあとから見つけていく インクリメントな設計でやっていけば良い 経験値を高めることが必要
奥田さん @yoskhdia
株式会社Socket アーキテクト?マネージャ? 落ち葉拾い症候群
かとじゅんさん
最近はICONIX大好き 分析をすっ飛ばして戦略の話をしたがる人が多い DDDの面白いところは分析のところ ICONIXはDDDにかなり効果がでている(セプテーニさんで一緒にやっているらしい) 最近のトピックはコンコース
—
成功事例について
DDDの本のやり方とかくらいしかない モデルを深化させて作った事例があまりないように感じるのになぜ多くの人がDDDを議論しているのか ソフトウェアの複雑さはドメインにあるとみんな思っているからではないか うまく行ってる人たちってほんとにいるの? 本で言われていることはほんとに有効なのか
- DDDで失敗してきた 顧客を巻き込めていなかった ビジネスパートナーとの連携を無視してしまった 政治的な文脈
戦術的なところで役に立ったことはあった(ヘキサゴナルアーキテクチャが威力を発揮したことはあったが、DDDのメインではない
DDDはカオスの辺縁(?聞き取れなかった)をもとめる作業 ユビキタス言語は目標 本人たちにも成功かどうかがわからないから成功事例が出てこないのではないか
@masuda220 成功事例が出てこないのは外から観察できないから 仕事が楽になる、楽しいようにするためにやっている やってよかったと思っている 話のシェアがみんなの財産になる 常に失敗だと思っている
@上坂さん ドメインに注力しているとお客さん的に外に出せない DDDをやろうとしている人たちはストイックで、ずっと追い求め続けてしまっている → 終われない
昔ながらのオブジェクト指向にくらべてDDDがいいのは戦略面的に優れている 経営者からしたらコアドメインは「金のなる木」 エンジニアサイドとビジネスサイドがユビキタス言語で一緒に考えられるのがいいところ
ドメインとビジネスが紐付いてこない サポートが必要
ICONIXとDDDは補完関係
性能がKPIにインパクトに与えるのであればDDDは必要ない
非機能要件もドメインと言えるのではないか @羽生田さん
WEB業界は比較的エンジニアサイドとビジネスサイドはユビキタス言語に近いもので喋れている
DDDの人はドメインによりすぎているイメージがある
シュレイヤメラン?
エヴァンスのこだわるドメイン 一般論としてのドメインを言いたいのではない ビジネスの人がテクニカルなことを言って良い 非機能要件なこともドメインに含めてもよい エンジニアだけでなくビジネスをやってる人間も含めて、開発においてどのくらいの時間、コストを掛けてやるのかを議論する ↑たしかに!
エヴァンスは実際に自分が経験したことのみを書いているだけ
問題領域をエンジニア、ビジネスサイドで議論することを追い求めている 問題領域はテクニカルなところではない
ドメインと境界づけられたコンテキストの違いって? ドメイン: 問題領域全体 境界づけられたコンテキスト: 解決すべき問題領域
— 豆蔵宣伝 —
InfoQは豆蔵が運営してる InfoQ Japan翻訳者募集中
— 豆蔵宣伝 —
セプテーニ 下村さん ツイート禁止
ユースケース駆動開発でドメインモデル(ユビキタス言語)を抽出(蒸留)
ユースケースを書いてみるとドメインモデル上にない言葉が出て来る
ユーザー、グループがメインだ!というふうに言っていても、ユースケースを声に出して見ると実はパーミッションが・・・とか出て来る
エンジニアの日本語力・・・
集約の話
ドメイン駆動設計のサンプルを見るのがよい エヴァンスはDBのトランザクションの話はしていない ロジックの置き場所としての集約の設計とDBのトランザクションの集約は別物として考えなければならない どこまでのロジックの置き場所かがドメイン駆動設計における集約
Write/Readの集約(ドメインモデル)は別物 @masuda220 集約単位でモデルが存在 Request Modelは集約にニアリーイコール Response Modelはそうではない可能性もある
応募者と求人企業 仕事という概念はそれぞれ違うものがある 求職者ドメイン企業側ドメインと分けてみたこともある @masuda220 アクターの捉え方によって概念は違う
関数型言語でもモデル駆動設計は実践可能か
言語によるものではない やりやすさやりにくさはあるとは思う 関数型は実社会で使うにおいて成熟しきっていない
純粋関数型だと・・・ ↑型クラスを自分で実装すれば良いのでは? @かとじゅんさん
オブジェクト指向は国語 関数型は数学
国語と数学を分けるのは何か? 国語は人によって捉え方が異なる 数学は一次曲線のように数式になっていたら誤解がない
エリックがQCON(2011年で来日した時に話を聞いたら、clojureを利用していた DDDが出来るかどうかはわからないと言っていた
どの言語を使うかはチームの話 Javaを使いたいチームであればScalaを選ぶ必要はない
Scalaはマルチパラダイムでいろいろな書き方が出来てしまうので難しい だれかがルールブックになって制御しないといけない
メソッドにユビキタス言語を用いる
オブジェクト指向はT(クラス)に従属 関数型はF(メソッド)に従属
年齢計算とかのFより、年齢とか誕生日のTが先に見つかる
大多数はFが先に見つかるのかも マクドナルドでバイトするという大きなF Fはマニュアル
要求の捉え方
T従属の発想は現実に近い
正しいTとFは見つからない リファクタリングをするときにTのほうが楽だ @masuda220
- 作者: Eric Evans
- 出版社/メーカー: 翔泳社
- 発売日: 2013/11/20
- メディア: Kindle版
- この商品を含むブログ (5件) を見る
- 作者: ヴァーン・ヴァーノン
- 出版社/メーカー: 翔泳社
- 発売日: 2015/03/19
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
- 作者: ダグ・ローゼンバーグ,マット・ステファン
- 出版社/メーカー: 翔泳社
- 発売日: 2016/01/28
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
JJUG CCC 2016 Fall で発表をしたという記録
発表しました
2016年12月3日(土)に開かれたJJUG CCC 2016 で発表をさせていただきました
↓資料はこちら
www.slideshare.net当日は会場にいっぱい人が入っていて、焦りました。
席も少し増やしていただけたようで大変恐縮です。
内容について
資料を作っていくうちにどこを対象として作成すべきなのかがわからず、結果的にDDDをあまり知らない人向けの内容になってしまい、既存プロジェクトにどう適用していくのかというところが薄くなってしまったのは反省です。 (というかまだどうあるべきかは勉強中で悩んでいるところなので、そこを発表する自信がなかった・・・)
↓に参加していろいろと情報を仕入れようと思っています。
また、このようにまとめていただけたこと非常に嬉しく思っています。
ドメインくどう設計とScala 既存プロジェクトへの適用を聞いてきたメモ #jjug_ccc #ccc_ab5 pic.twitter.com/mKki1pJDxF
— Nakayama san (@nakayama_san) December 3, 2016
補足
発表自体は完全にDDDを取り入れているかのように思われたかも知れませんが、まだ全然です。(コードの一割にも満たないくらい)
なので、ぜひ一緒にDDDを進めてくれる方を個人的には求めています。
途中の発言でSIerをディスるような発言があったと捉えられた方がいるかもしれませんが、僕は前職のSIerでいろいろと学びましたし、一緒に働いていた方々の大半は素晴らしい人達ばかりだったと思っていますので別にディスったつもりはありませんので、ご承知おきを。(そのへんはわかっていただけているとは思っていますが念のため) ディスるとしたら残業時間と組織のあり方というか仕事の進め方、技術に興味のない方々なので、皆様方に於かれましては別にディスられたと感じる必要はないです。
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
- 購入: 19人 クリック: 1,360回
- この商品を含むブログ (131件) を見る
実践ドメイン駆動設計 (Object Oriented SELECTION)
- 作者: ヴァーン・ヴァーノン,高木正弘
- 出版社/メーカー: 翔泳社
- 発売日: 2015/03/17
- メディア: 大型本
- この商品を含むブログ (4件) を見る
Angular2 Form
↑のサンプルどおりに作ればOK
<div class="container"> <h1>Artist Form</h1> <form #artistForm="ngForm" (ngSubmit)="onSubmit(artistForm)"> <div class="form-group"> <label for="name">Name</label> <input type="text" class="form-control" ng-control="name" id="name" name="name" required ngModel #name="ngModel"> </div> <button type="submit" class="btn btn-default">Submit</button> </form> {{name.value}} </div>
- name属性は必要
#artistForm
というのは変数名 artistForm に "ngForm" を入れるという意味- "ngForm" は ngForm ディレクティブ ?
import { Component, OnInit } from '@angular/core'; import { NgForm } from '@angular/forms'; @Component({ selector: 'app-artist-form', templateUrl: './artist-form.component.html', styleUrls: ['./artist-form.component.css'] }) export class ArtistFormComponent implements OnInit { constructor( ) { } ngOnInit() { } onSubmit(f: NgForm) { console.log('----------------', f.value) } }
Angular CLI
play slick で Connection is not available になった
Connection is not available,
configの書き方が変わったらしい
slick { dbs { default { driver= "slick.driver.MySQLDriver$" db { dataSourceClass = "slick.jdbc.DatabaseUrlDataSource" properties { driver = "com.mysql.jdbc.Driver" url = "jdbc:mysql://localhost:3306/<スキーマ名>?characterEncoding=UTF-8&serverTimezone=UTC&nullNamePatternMatchesAll=true" user=root password="" } url = "jdbc:mysql://localhost:3306/<スキーマ名>?characterEncoding=UTF-8&serverTimezone=UTC&nullNamePatternMatchesAll=true" } username=root password="" } } }
- 作者: 竹添直樹,島本多可子
- 出版社/メーカー: 翔泳社
- 発売日: 2012/07/03
- メディア: 単行本(ソフトカバー)
- 購入: 6人 クリック: 54回
- この商品を含むブログ (14件) を見る
Choreographyについて雑多に書き出して考えてみる
マイクロサービスアーキテクチャを考える基に
Choreography・コレオグラフィー
pub/sub
RabbitMQ? akka?
とりあえずakkaで考えてみる。
理屈
- Publisher(顧客サービス)
- Topic(顧客イベント)
Subscriber(ロイヤリティポイントサービス、郵送サービス、メールサービス)
Subscriberはどのイベントの時に呼び出されるべきかをTopicに登録する(購読)
- 顧客サービスがTopicに対してイベントをPublishする(出版)
- イベントが発行されたことをSubscriberが検知する
Note
なんかこのやり方だと、TopicとSubscriber側で両方デプロイしなきゃいけない気がするけど、それはいいのかな?
Publisher, Subscriber
Playframework, finatra等で良さそう
Topic
akka-remote http://kimutansk.hatenablog.com/entry/20140924/1411509232
理屈はわかった、じゃあ実際の作りは?
- クライアントが顧客サービスに対して、顧客登録のリクエストを送信する
- 顧客登録のリクエストを受け付けた顧客サービスはTopicに対して顧客登録イベントを出版するためのリクエストを送信する
- Topicはリクエストを受け付けたら顧客登録イベントを出版する
- TopicのSubscriberは出版されたイベントを受けて、ロイヤリティポイントサービス、郵送サービス、メールサービスへリクエストを送信する
これでいいのか???
Note
メールサービスがロイヤリティポイントサービスの結果の値を必要とする場合には、Topic側でそのような作りにする必要がありそう。
etc
https://www.tothepoint.company/blog/microservices-the-most-occurring-obstacles/ http://microservices.io/patterns/microservices.html http://eventuate.io/exampleapps.html https://www.tothepoint.company/blog/microservices-the-most-occurring-obstacles/ http://pkaczor.blogspot.jp/2015/12/akka-ddd-integrating-eventstore.html
- 作者: Sam Newman,佐藤直生,木下哲也
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/02/26
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る