Release v6.7.0 · babel/babel
6.7.0 (2016-03-08) Notable changes: Various async function fixes (const read-only error, wrong this, etc) Proper sourcemaps for import/export statements Moved internal Babel cache out of the AST New Feature babel-traverse #3393 Move NodePath cache out of the AST. (@amasad) Move cache into a clearable WeakMap, adds traverse.clearCache and traverse.copyCache. This doubles as a bug fix because previo
2016-03-08のJS: React v15.0 RC、Reactパフォーマンス調査、DDD
JSer.info #269 - React v15.0 RC1がリリースされました。 React v15.0 Release Candidate | React New Versioning Schemeで書かれているように、Reactの次のメジャーバージョンはv0.14 -> v15.0となります。 v15.0 RC1ではdata-reactidがクライアントサイドのレンダリングではなくなる、nullをコメントとしてレンダリングするようになるなどレンダリングに関する変更がおこなわれています。 React v0.14でreactとreact-domにパッケージが分けられ、それぞれでメソッドも分離されたため非推奨となっていたメソッドがありました。 v15.0ではこれらの非推奨メソッドの削除や警告メッセージの改善などが行われています。 Performance Engineering with
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
エンティティの識別子をラップしたクラスを用意するとよい理由 | GuildWorks Blog
ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。 今回は、ドメイン駆動設計における、エンティティの識別子の実装面について考えてみたいと思います。（あまり本質的な話題でなくてすみません。。。） エンティティの識別子、どう実装していますか？ 私の場合、以下の図のようにエンティティが直接LongやStringなどプリミティブの型で持ってもよいと思っていました。エンティティの識別にしか使われないのでエンティティが直接持っていた方が使いやすいと思っていたのです。 ドメイン駆動設計本の例はどうでしょう・・・。 ドメイン駆動設計ではプリミティブの型を使用している例も載っていますが、書籍内のサンプルを実装したDDDSampleではVoyageNumberやTrackingIdなど識別子をラップしたクラスを使ってます。 実践ドメイン駆動
RailsでDDD - Qiita
別のアプローチによる実装の記事を書きました。 よろしければこちらもご覧ください。 「かんばん」を、DDDで設計しRailsで実装してみました。 kanban_core_extension 現時点では、最小限の機能しかありませんが ドメイン駆動設計をRailsで実装する際の一例として参考になれば幸いです。 アプリケーションの機能 開発するフィーチャ（タスク）をカードで表現し、進捗状況をかんばんボードで可視化する カードを次のフェーズ（進捗の区切り）に進める時にWIP制限をチェックする アーキテクチャスタイル Event SourcingなしのCQRSです。 変更（Command）の時だけドメインモデルを使います。 問い合わせ（Query）では、必要なデータをデータベースから直接取得します。 リポジトリからドメインモデルを取得することはしません。 取得したデータは構造化されたオブジェクトですが
CQRS + Event Sourcing
This document provides an overview of CQRS (Command Query Responsibility Segregation) and Event Sourcing patterns when dealing with distributed systems and databases. It discusses that in distributed systems, it is not possible to satisfy all three guarantees of consistency, availability and partition tolerance at the same time according to Brewer's CAP theorem. It also describes how CQRS separate
某S社のddd(メイリオ)
Java/Spring Boot/MyBatis/Thymeleafを使った、ドメイン駆動設計のサンプルコード。ビジネスルールに焦点を合わせ、計算モデルで複雑さを整理し、型指向のプログラミングで実装する、その具体例。
20151110 ドメイン駆動設計によるサービス開発
ビッグローブでDDDを導入して早２年。 この２年間、ISP事業における主要なサービスをDDDで開発してきて、試行錯誤の連続でした。 今回は、試行錯誤の過程を経て生まれた、実際に実践している ・設計・実装の考え方（ドメインモデルやコード例やDB設計など） ・チーム環境の考え方（開発プロセスやチームビルディングなど） の２つを軸に現場でのリアルな体験を紹介します。 また、最後に、試行錯誤における失敗談も紹介します。 Read less
Private Presentation
Private content!This content has been marked as private by the uploader.
混乱しがちなサービスという概念について - かとじゅんの技術日誌
社内でサービスがよくわからないという話になったので、考察を少しまとめておきます。 過去のエントリでも以下のように触れましたが、もう少しかみ砕いてみよう。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。 まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されていま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - IndigoUnited/node-cross-spawn-async: A cross platform solution to node's spawn
What's the difference between JavaScript and Java?
Greg Young - CQRS and Event Sourcing - Code on the Beach 2014