CQRSの小さな演習(1) 現実の問題 - 考える場所
2016 - 02 - 20 CQRSの小さな演習(1) 現実の問題 作ったもの 考えたこと システム開発とエンジニアリング ドメイン駆動設計 CQRSの小さな演習 仕事で業務向けのWebアプリケーション開発をしています。その中でもいろいろな問題がやはりあるのですが、特に大きな問題だなと思えることがあります。エンハンスや保守改修が続くと、もうなにがなんだったか分からなくなってしまうことです。私はもう20代でもなくて、記憶力が衰えてきているということもあるのですが、問題はそこではないでしょう。むしろ、個人の記憶力が頼りになってしまうというのはおかしいことです。しかし、それが現実だということです。 仕事ではどうしてもこの現実から脱却できないということがあります。正直なところ、モダンな開発スタイルを取り入れている現場の雰囲気は分かりません。私が長いこと携わっている現場がそうではないからです。優先
DDD: ImmutableなEntityの実装方法〜ステートソーシングなEntityとイベントソーシングなEntity〜 - Qiita
DDD: ImmutableなEntityの実装方法〜ステートソーシングなEntityとイベントソーシングなEntity〜ScalaDDDドメイン駆動設計 ドメイン駆動設計では、Value ObjectはImmutable、EntityはMutableという雰囲気があるように思うが、ScalaでDDDを実践しようとなると、EntityがMutableでは逆に実装が複雑になることが多い。僕がDDDを始めた2013年頃は、ImmutableなEntityの実装に関する情報がほとんどなく実装方法を試行錯誤していた。その中で、個人的にImmutable Entityの実装方法が落ち着いてきたので、僕がどのように実装しているかについて紹介したい。 なお、ここで紹介するScalaコードはGitHubのsuin/scala-playgroundで公開しているので、コンパイル・実行など試してみたい場合はご
iOS Clean Architecture - 騒音のない世界 BLOG
iOS その2 Advent Calendar 2016 15日目の記事です。 現在業務で製作中のアプリではClean Architectureを採用しています。アプリ自体はまだリリースされていないのですが、少しずつ全体像は見えてきたのでClean Architectureの概要と合わせて具体的な実装例の紹介と現時点での所感などを書きたいと思います。 Clean Architecture とは 概要 iOSアプリにおける実装 3つのグループ分け Presentation Domain Data 所有関係・依存関係 Clean Architectureから外れたもの メリット・デメリット メリット テスタビリティが向上する 再利用性が向上する 機能を置き換えやすくなる 見通しが良くなる デメリット 学習コストが高い 面倒なことが多い ライブラリやSDKの設計思想と食い違う 最後に 参考文献
Reduxの正しい解釈の話
2016年の課題は状態遷移の管理だったと思う。 そのアンサーとして、 Fluxのような実装におけるStore相当にアプリケーションの状態をほぼすべて管理させるReactのようなVirtual DOMを搭載したビューの実装を透過的なユーザーインターフェースとして扱うこの2つの組み合わせにより、アプリケーションの状態と描画される画面が (ほぼ) 参照透過的になる。というのがFluxとReact以降のパラダイムだと思う (理論として) 。 このパラダイムなら、エラーの発生時にアプリケーションの状態を表現するJSONをエラー収集サービスに送るようにして、簡単にバグを再現したりできるし、状態の遷移をテストしていくことで、クラッシュするようなバグのうち大半を検出できる。 Fluxの問題そこで問題が出るのが、Action(Creator) とReducer (Store#reduce())の2要素間のル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
