Ayende @ Rahien

Gauthier Segay commented on Adaptive Domain Models with Rhino Commons

Thu, 27 Mar 2008 23:28:45 GMT

I would name that faceted interface approach, it make sense to me for separation of concern. The concern is that when a given client need two or more facets to work with... Here mixin or some interface composition scheme would be great. IOrderSummaryPresenter.PresentOrder(mixin::(IOrderCalculator, IOrderInspector) orderRepresentation) // ugly syntax

Udi Dahan commented on Adaptive Domain Models with Rhino Commons

Thu, 27 Mar 2008 20:18:19 GMT

Victor, The number of interfaces you'll have in the system corresponds to the number of use cases. I've worked on very large systems and have not seen "zillions of interfaces" using this pattern. Further, the larger the system, the more we find sub-domains so that the relative surface area a developer sees stays capped.

Colin Jack commented on Adaptive Domain Models with Rhino Commons

Thu, 27 Mar 2008 15:46:04 GMT

Hadn't noticed the term "header interface" before, nice. To be fair my main problem with a lot of advice on interfaces is that it doesn't focus enough on role interfaces, instead it just assumes that extracting any old interface will improve your design. Anyway so far we've tended to use role interfaces for associations between domain modules, and in those situations they work a treat.

Ayende Rahien commented on Adaptive Domain Models with Rhino Commons

Thu, 27 Mar 2008 15:24:23 GMT

Udi does.

Victor Kornov commented on Adaptive Domain Models with Rhino Commons

Thu, 27 Mar 2008 15:22:34 GMT

... which eventually leads here http://www.objectmentor.com/resources/articles/isp.pdf One thing that bothers me is... Does anyone have a real world experience with "role interfaces"? Does it scale? Won't it lead to kind of "zillion interfaces" antipattern? You see, coarse grained interfaces have their place too.

Victor Kornov commented on Adaptive Domain Models with Rhino Commons

Thu, 27 Mar 2008 15:12:02 GMT

Fowler talks the same here http://martinfowler.com/bliki/RoleInterface.html

Colin Jack commented on Adaptive Domain Models with Rhino Commons

Thu, 27 Mar 2008 14:18:52 GMT

@Ayende Not sure, repositories are related to aggregates so breaking that link seems to me to be moving away from DDD? I know that technically its still based on aggregates, but surely the link is now less directly. Also to me bounded contexts are something different again, at a higher level (about tying your model to a particular context). That was my understanding of Evans' use of the term.

Ayende Rahien commented on Adaptive Domain Models with Rhino Commons

Thu, 27 Mar 2008 14:06:42 GMT

Colin, The interface for the entities actually improve the DDDness of the code. You can think of them as bounded context view into the entity

Colin Jack commented on Adaptive Domain Models with Rhino Commons

Thu, 27 Mar 2008 13:47:37 GMT

@Ayende "Having to do something like order.Lines.Total is messy from my point of view. You need to write a lot more code, violate the law of Demeter, and deal with a lot of cases that are inapplicable (custom collection with lazy loading) if you don't go there." Originally I thought the same but I find custom collection classes help clarify things a bit, otherwise your aggregate roots interfaces can get cluttered (though you'd handle that with interfaces). Anyway I think moving some behavior to the collections and forcing you to do order.Lines.Total is OK, not least as the collection itself has domain meaning so I don't mind talking about it. "Two interfaces for a service is a bad thing, for entity, it is a good idea." You could be right but when do you use them? Is it for cross (domain) module situations, only for customizing them for use by the upper layers or maybe for all cross-aggregate associations? I definitely use them cross module but so far I've been happy to let the "upper" layers access the entities directly or for different aggregates to directly reference each others roots.

Colin Jack commented on Adaptive Domain Models with Rhino Commons

Thu, 27 Mar 2008 13:38:14 GMT

Yeah I read Udi's posts a while back, interesting stuff. I must admit I've never really thought role interfaces made sense on our domain model but I'm always interested to see how others use them. Anyway it does worry me slightly that the main driver could end up being performance and that in the process we migth lose some of the essence of DDD. Not sure though. It also seems odd now seeing repositories returning not aggregates but just single views onto an aggregate. Plus one of the key things about an aggregate is that when you commit your changes to it the aggregate should ensure all invariants within the aggregate are satisfied. However what happens if that means accessing data that you haven't retrieved for the little interface you requested. I know you could change the fetching strategy but its just getting more complex, though maybe there are workarounds. More specifically on this example having repositories create objects, and seemingly without passing in arguments seems quite restrictive. Having said that I haven't seen the code before so maybe I'm missing something. It is interesting how differently people practice DDD. Some people use AOP a lot, some people use heavyweight service layers, this approach, some people use IoC to inject validation rules etc etc.

Ayende Rahien commented on Adaptive Domain Models with Rhino Commons

Thu, 27 Mar 2008 13:26:35 GMT

You don't resolve an Order, it is an entity. Two interfaces for a service is a bad thing, for entity, it is a good idea. I disagree about the way to handle total. Having to do something like order.Lines.Total is messy from my point of view. You need to write a lot more code, violate the law of Demeter, and deal with a lot of cases that are inapplicable (custom collection with lazy loading) if you don't go there. I can see you point for order.Total, however, and then it is just a case of what exactly it does. If it is a simple summation, sure. But it can also be something like: public Money CalculateTotal(IDiscountService, IProductCostRules[] rules); As for this: IOrderCalculator a = Repository.Get(1); IOrderAdder b = Repository.Get(1); You get two references to the same object, not two instances.

Francois Tanguay commented on Adaptive Domain Models with Rhino Commons

Thu, 27 Mar 2008 12:08:50 GMT

So if I resolve both interfaces, will I get 2 different instances of the Order? Or should it be that you can register both interfaces for the same concrete type? (remember we had this discussion on Unity forums) In my book, there is no such thing as CalculateTotal(). There is a Total derived(calculated) property and it is on a OrderLineCollection with many other properties that correspond to all lines as a whole.