Comments on: Design for Testability and “Domain-Driven Design”

By: David Stull

David Stull — Thu, 24 Sep 2009 01:00:00 +0000

Misko, I really enjoy your articles. I have learned a lot. This post deals with some questions that I had thought a small, but complete sample app would be very helpful to clarify. Any interest in providing one?

By: Igor Brejc

Igor Brejc — Tue, 17 Mar 2009 21:19:20 +0000

@Miško, I guess it depends on the nature of the behavior (and the domain it tries to describe) – sometimes it is appropriate to put that kind of domain logic into an Invoice object. Sometimes a separate service or strategy pattern is more suitable. As for your reservations about having non-persistable fields, I would say the best way would be to hide the domain from the persistance technology (like Hibernate) through some kind of factories and repositories. Then you wouldn’t have to worry how these fields get filled (at least not from the domain point of view).In the case of invoicing (of which I’m not an expert): maybe a ITaxation service which would accept Invoices as arguments in the Tax method would be a solution? In that case an Invoice would not care about the tax table in the first place.

By: misko

misko — Tue, 17 Mar 2009 13:55:07 +0000

@Igor, After reading http://martinfowler.com/bliki/AnemicDomainModel.html I agree with Fowler, your objects should have appropriate behavior on them. As he puts it “The logic that should be in a domain object is domain logic – validations, calculations, business rules – whatever you like to call it.” The point I am trying to make is that it is not where the behavior is, but rather how this behavior gets a hold of its collaborators. What if your DomainModel is an Invoice and the calculation behavior need to get a hold of TaxTable to do the job. How should the Invoice get a hold of TaxTable? Here my point is that the TaxTable should not be a field of DomainModel, therefor TaxTable can not be constructor injected.

By: igorbrejc.net » Fresh Catch For March 17th

igorbrejc.net » Fresh Catch For March 17th — Tue, 17 Mar 2009 11:04:58 +0000

[...] Design for Testability and “Domain-Driven Design” [...]

By: Igor Brejc

Igor Brejc — Tue, 17 Mar 2009 07:11:09 +0000

Miško,This is a very interesting topic, which I was raising in my head ever since I read Martin Fowler’s post about anemic domain models (http://technorati.com/search/http://martinfowler.com/bliki/AnemicDomainModel.html) – this got me into DDD area, so I started reading Eric’s book (I’m halfway through it). What’s your opinion about anemic domain models? BTW I’m not sure relying on a specific technology (like Hibernate) helps the discussion. I come from the .NET sphere and I (usually) do not use NHibernate for DB persistence. But I still want to be able to understand the implications of using either Eric’s DDD approach or some alternatives.