Comments on: Fluent Domain Methods

By: Summary 05.08.2009 « Bogdan Brinzarea’s blog

Summary 05.08.2009 « Bogdan Brinzarea’s blog — Wed, 05 Aug 2009 14:31:32 +0000

[...] Van Ryswyck talks about fluent domain methods for setting up complex aggregate roots and for implementing behavior on domain [...]

By: Jan Van Ryswyck

Jan Van Ryswyck — Tue, 04 Aug 2009 10:59:44 +0000

@Dokie: The Tags collection is exposed as an IEnumerable.

By: Dokie

Dokie — Tue, 04 Aug 2009 07:53:49 +0000

This looks good but I cannot see explicitly from this post or the former, but do you not expose the Tags collection via a public getter property called Tags on the Document class? The previous post showed code such as

var tagBuilder = new TagBuilder(tag =>
ProvideValueFor(document => document.Tags, tag));

which I interpret as having such a property. Whilst the backing field is retrieved for the collection (even if that is, and usually would be, private) to perform the actual Add call to the collection, if you expose the Tags collection and it is not a ReadOnlyCollection, then the consumer can simple add a Tag object without going through the Fluent building path or through the call to AddTag. Am I right in this analysis?

By: Dew Drop – August 3, 2009 | Alvin Ashcraft's Morning Dew

Dew Drop – August 3, 2009 | Alvin Ashcraft's Morning Dew — Mon, 03 Aug 2009 12:43:07 +0000

[...] Fluent Domain Methods (Jan Van Ryswyck) [...]

By: Reflective Perspective - Chris Alcock » The Morning Brew #403

Reflective Perspective - Chris Alcock » The Morning Brew #403 — Mon, 03 Aug 2009 09:11:31 +0000

[...] Fluent Domain Methods – Jan Van Ryswyck explores builiding domain objects with Fluent interfaces and takes a look at the structure of the fluent builder. [...]

By: Scott Bellware

Scott Bellware — Sun, 02 Aug 2009 22:34:49 +0000

Seems like named parameters would make questionable that which is proposed here as a clear advantage of method chaining.

By: Mike

Mike — Sun, 02 Aug 2009 21:02:48 +0000

@Jan
Thanks for the reply. Sorry to freak you out though… I pressed forward with this approach frequently into my current project and found it very simple to extend. Something itches me about injecting such builders into my entities at construction but it’s great to have this functionality should the need arise.
Keep up the good articles !
Mike

By: Jan Van Ryswyck

Jan Van Ryswyck — Sun, 02 Aug 2009 19:34:05 +0000

@Mike: I personally don’t consider this as a violation of SRP. In my post, I linked to a post from Udi where he advises to “always get an entity”. It is the duty of an aggregate root to enforce its boundaries. I therefore consider the expression builder being a part of the domain. In my example, the value object is not created by the aggregate root, but by the expression builder itself. The aggregate only adds to its collection.

After reading your article, I must say that the resemblance of the phases we’ve been through freaks me out . If you want your domain entity to return a different builder (your example talks abot different signatures), then one might put this in a seperate ‘BuilderFactory’. NH 2.1 now supports IoC, so such a factory can be injected into a domain object when retrieved from NH.

One of the major advantages in using expression builders this way is loosening up dependencies on the domain. My 2 (Euro)cents.

By: Mike

Mike — Sat, 01 Aug 2009 22:05:59 +0000

@Jan
I implemented a similar pattern on my blog a while back and got heat from some who thought I was violating SRP by allowing my agg root to return such a factory/builder…everyone wanted me to inject it. My opinion though is that the very notion of an Aggregate Root ‘violates’ SRP by placing both the behavior of an entity _and_ the role it plays as the root…and I’m ok with that. Any thots?