タグ

2017年7月10日のブックマーク (2件)

  • RDRA DDD Agile

    11. サービスの会社が 業務システムに取り組む話 • アソビュー • 全国のレジャー・遊び・体験が探せる日最大 級の検索・予約サイト • バックオフィス業務は必要最小限、かつ人間系 でがんばっているが… • 事業のさらなら発展のためには • バックオフィスのシステム充実が必須 • ただし、 • ビジネスモデルや業務フローは変わり続ける 12. 電子チケットサービス • ネット上で電子チケットの購入 • 入場時に、電子チケットの提示と「もぎり」 • 挑戦 – 金流の変更 • before : 主催会社にお金が入り、手数料を請求 • after: アソビューにお金が入り、主催会社に支払い – バックオフィス業務の複雑化 – 確実性や迅速性の要求 – バックオフィスシステムの開発経験不足

    RDRA DDD Agile
    k1take
    k1take 2017/07/10
    このスライド中に実際ドメイン駆動設計している最中の成果物が出てるけど、全部写真。設計書は出て来ない。これで行けるのは確か。(最後に納品用に創るかもだけど)。
  • 現場で役立つシステム設計の原則 - ひしだまの変更履歴

    ひしだまHPの更新履歴。 主にTRPGリプレイの元ネタ集、プログラミング技術メモと自作ソフト、好きなゲーム音楽です。 『現場で役立つシステム設計の原則』が話題になっていたので、(流し読み程度だけど)読んでみた。 基的にはJavaがベースで、前半(というか最初の2章くらい)はコーディングレベルの話、残りはオブジェクト指向ベースの設計方法の話。 あ、ちなみに自分は最近はAsakusa Frameworkというバッチフレームワークを使う仕事が多いのでバッチ寄りの考え方で読んでいるけど、書は基的にウェブ寄り(Spring Framework)の思想っぽい。 コーディングレベルの話はとても納得。Javaでプログラミングする人は全員これを確認しておくべきという感じ。 (とても細かいレベルの事を言うと、if文の処理部分は波括弧で囲んだ方が(余計なバグが入る余地を減らせるので)いいと思う。ただ、書

    現場で役立つシステム設計の原則 - ひしだまの変更履歴
    k1take
    k1take 2017/07/10
    増田さんと、RDRAの清水さんと話したことあるけど、コードも要件も仕様も変化して成長するから、設計書は極力ちから入れず、せいぜいスナップショットとしてホワイトボード写真とるって仰ってた。WFには適用できないぽ