Comments on: CouchDB and Domain-Driven Design http://bradley-holt.com/2011/08/couchdb-and-domain-driven-design/ Mon, 29 Sep 2014 19:50:55 +0000 hourly 1 https://wordpress.org/?v=4.6.1 By: Christopher Hlubek http://bradley-holt.com/2011/08/couchdb-and-domain-driven-design/comment-page-1/#comment-3683 Mon, 05 Sep 2011 15:52:57 +0000 http://bradley-holt.com/?p=1251#comment-3683 We already implemented a CouchDB persistence backend (http://git.typo3.org/FLOW3/Packages/CouchDB.git) for FLOW3, a DDD centric PHP framework. It works exactly like stated in your article, but we don’t persist complete aggregates for now, since it is somewhat more pragmatic being able to access each entity individually. Right now value objects are embedded into the document which fits the paradigms nicely. Maybe the document aggregate boundary mapping will come later.

]]>
By: Bradley Holt http://bradley-holt.com/2011/08/couchdb-and-domain-driven-design/comment-page-1/#comment-3543 Wed, 03 Aug 2011 13:25:46 +0000 http://bradley-holt.com/?p=1251#comment-3543 @sokzzuka: There are a couple of reasons why I modeled a Person as a Value Object instead of an Entity. First, it made the explanation of the main topic much easier. If the Aggregate contains objects that are Entities (other than the Aggregate Root), it would have brought up several other design questions that could have distracted from the main point.

Second, I was basing my model on the Atom Entry Document in the Atom Syndication Format, referencing this as a Published Language[1]. Following that model, I interpreted the Person construct[2] as a Value Object. A Person “has one required element, name, and two optional elements: uri, email.” An Entity must have an identity. Without extending or modifying the model, which element would you pick as the identifier? URI or email seem to make sense, but those are optional fields. Identifiers can’t be optional. The name field is not an appropriate identifier as more than one Person can have the same name (and thus different URIs and emails). Since there is no appropriate identifier, that leaves us with treating a Person as a Value Object within the Atom Syndication Format domain.

[1]: Domain-Driven Design, Part IV. Strategic Design, Chapter 14. Maintaining Model Integrity, Published Language
[2]: http://www.atomenabled.org/developers/syndication/#person

]]>
By: Bradley Holt http://bradley-holt.com/2011/08/couchdb-and-domain-driven-design/comment-page-1/#comment-3542 Wed, 03 Aug 2011 13:03:52 +0000 http://bradley-holt.com/?p=1251#comment-3542 @cordoval: Check out the slidecast from a presentation I did at NY PHP about CouchDB:
http://www.slideshare.net/bradley.holt/couchdb-at-new-york-php

]]>
By: sokzzuka http://bradley-holt.com/2011/08/couchdb-and-domain-driven-design/comment-page-1/#comment-3540 Tue, 02 Aug 2011 19:44:41 +0000 http://bradley-holt.com/?p=1251#comment-3540 I think, that a Person is not a ValueObject because it has a thread of continuity and identity (specificaly in the domain of a blog entry). Also I think that in context of persisting entities and other objects you may use Doctrine 2 Object Document Mapper for MongoDb.

]]>
By: cordoval http://bradley-holt.com/2011/08/couchdb-and-domain-driven-design/comment-page-1/#comment-3539 Tue, 02 Aug 2011 19:01:29 +0000 http://bradley-holt.com/?p=1251#comment-3539 not sure i follow, perhaps it is too high level, do you have an itro for couchdb programming? can you lower your explanations for a newbie to get up to speed in understanding this please? thanks!

]]>