DDD Reference - Domain Language
A summary of the patterns and definitions of DDD. This document is meant as a convenient reference for those who know the principles of Domain-Driven Design (DDD). It does not contain full explanations of DDD or even of the terms and patterns covered. It is intended to be used as a complement to books and other resources available to those learning about DDD. The DDD Reference contains a brief sum
Search
Releases, Offers & More Be the first to hear about our newest content, best promotions and upcoming events. Plus get 25% off your next purchase. Newsletter Sign Up Download Accounts Your email address is your account identifier. You can create a password, or just download from the links sent via email. My Orders (Resend order emails) How We're Different Hands-on instructions Solutions to real-worl
新しいモデリング手法: EventStormingをはじめるための準備 - yoskhdia’s diary
EventStorming (イベントストーミング) というモデリング手法があります。 www.eventstorming.com EventStorming is a flexible workshop format for collaborative exploration of complex business domains. EventStormingは、複雑なビジネスドメインを協同的に探求するための柔軟なワークショップ形式のひとつです。（意訳） 考案者はAlberto Brandolini氏で2013年にはブログに最初の投稿がされています。 海外での認知度は高く*1、Eric Evans氏のプレゼンテーションの中でも強力な手法であると言及*2されています。 近々、この手法を試せる機会が来そうなので、そのやり方について（私見を交えつつ）まとめてみるエントリです。 注意 現在進行系
DDDに関する質問にバシバシお答えしました [ドメイン駆動設計] - little hands' lab
先日、メディアマックスジャパン様(以下、MMJ様)にお邪魔してドメイン駆動設計勉強会を開催してきました。そちらで質疑応答セッションがあり、実際にドメイン駆動設計で開発をしだしたタイミングで出てきた具体的な疑問について色々お答えしました。 おそらく多くの人が同じような疑問を持たれそうな内容だったので、MMJ様の許可を得てこちらでも紹介したいと思います。 コンテキストの分け方について DBを複数コンテキスト共通でつかっていいのか？ スキーマわけなくていいのか？ コンテキストごとにスキーマは最低限分けることをオススメしています。詳細は以下の記事をご参照ください。 little-hands.hatenablog.com 機能ごとに切る？ユーザ種別ごとにコンテキストわけるべきなのか？ コンテキストの切り方が正しいかどうか、どうやって判断すればいいか？ コンテキスト設計は、従えば作れるようなフローチャ
![DDDに関する質問にバシバシお答えしました [ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/13f84b8758b38db7917b04405e41e71b2b5f7c43/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171221%2F20171221134405.png)
ユースケース仕様の事前条件とは - mkoszk’s blog
事前条件とは ユースケース仕様の事前条件は、平たく言うとユースケースを開始する前に「すること」と「あること」を記述したものです。事前条件の「条件」は、「今日のコンディションはどうですか？」というときのコンディションに近いニュアンスがあります。ある「状態」が「条件」としてみなされます。ですから、事前条件はユースケースを開始するために、アクターとシステムが満たすべき状態のことと言えます。ユースケースを実行する前のエンティティの遷移前状態、「概念」の状態も含まれます。 事前条件は、起動予定のユースケースが依存している先行のユースケースの完了状態と関係があります。 事前条件は、対象システムが何らからの形でその条件を知ることのできるものです。 事前条件は、ユースケースの開始前にシステムによって真であることが保障されている事柄のことです。ユースケースの開始に先行して成り立っていなければならない条件を記
UseCaseの再利用性 - yoskhdia’s diary
Clean ArchitectureにはUseCase層が定義されていますが、このUseCaseが一体どういうものなのか度々わからなくなるので、自分の考えをまとめてみるエントリです。 Clean Architectureについてはこちら 8thlight.com 日本語訳：クリーンアーキテクチャ(The Clean Architecture翻訳) 以降、概念を”ユースケース”、実装されるモノを”UseCase”と表記することにします。 （同じっちゃ同じなんですが、指してるものがところどころ変わるので表記分けをしています。） また、Webアプリケーションを想定しています。 ユースケースとは何なのか Clean Architectureから抜粋します。 Use Cases The software in this layer contains application specific busi
DDD with RDRA, ICONIX
DDDを具体的なプロセスに落とし込むにはどういう観点が必要だろうか。 - 境界づけられたコンテキストがどこまでの範囲かよくわからない - ユビキタス言語やドメインモデルをどのように発見すればいいかわからない。どこから着手すればいいのか？ - ドメインモデルがただのデータの入れ物になってしまう(貧血…
Almin 0.12リリース: Read層におけるState更新のアプローチ
Almin 0.12をリリースしました。 Release Almin 0.12 · almin/almin StoreとStoreGroupが書き直されたので色々変わっていますが、マイグレーションツールでアップデートできます。 変更点 StoreGroupを書き直した Before: class AStore extends Store { getState() { return {a : "a value"}; } } class BStore extends Store { getState() { return {b : "b value"}; } } const aStore = new AStore(); const bStore = new BStore(); const storeGroup = new StoreGroup( aStore, bStore ]); conso
Domain Modeling with Functions - an algebraic approach
The document discusses domain modeling using an algebraic approach with functions. It explains that a domain model describes entities, attributes, roles, relationships and constraints in a problem domain. It advocates modeling the domain as an algebra of types and functions, with types representing entities and functions representing behaviors. This approach uses algebraic data types to define imm
大規模Webアプリケーションにおける複雑性とアーキテクチャ設計に関する一考察 - Qiita
Webアプリケーション開発についての知見を、自分の経験と知識をベースに整理してみようという試みです。 いわゆるサーバサイドにスコープを絞り、フロントエンドは対象外です。筆者は普段、オブジェクト指向言語で書いているので、本記事でもその前提（Ruby、PHP、Python、Java、Scalaあたりを想定）になっています。 では、本編をどうぞ。 ソフトウェア開発は複雑さとの戦い 『人月の神話』では、ソフトウェアの本質的な困難性について4つの性質をあげている。その中で最初に出てくるのが「複雑性」である。『新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡』なんか読んでもらえると、ソフトウェアの複雑性と戦うために、人類が生み出してきた発明の数々が説明されている。 では、複雑さとは何か？もう少し掘り下げて考えてみよう。 複雑さの正体 Webアプリケーションが複雑になる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - ddd-by-examples/library: A comprehensive Domain-Driven Design example with problem space strategic analysis and various tactical patterns.
Eric Evans - Keynote: DDD Isn't Done: A Skeptical, Optimistic, Pragmatic Look - YouTube
集約の設計と実装
Explore DDD
GitHub - almin/almin-usecase-map-generator: Command line tool that generate UseCase map from almin's UseCases.
Amazon.com: Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series): Robert C. Martin: Book
Maturing Your Microservices Applications with CQRS (Ep. 19)
Modeling with Aggregates
Building a CQRS/ES web application in Elixir using Phoenix - Binary Consulting
GitHub - talyssonoc/structure: A simple schema/attributes library built on top of modern JavaScript
