The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

lili5058 (2) [Avatar] Offline
I'm enjoying this book immensely and really appreciate the walk-through of the thinking process.

I'm currently reading chapter 3 and have a question about the parameters to the updateDeliveryInfo() method on PlaceOrderService.

According to E. Evans in DDD the method signatures of Domain-Model Services should be expressed in terms of Domain Model objects. (p. 105 of Domain-Driven Design).

Chapter 3 shows the method signature to be:

[pre]PlaceOrderServiceResult updateDeliveryInfo(String pendingOrderID, Address deliveryAddress, Date deliveryTime)[/pre]

which uses a String-type pendingOrderID to look up the PendingOrder, rather than receiving a PendingOrder instance directly.

If this were a 'true' domain-model service, it would receive the PendingOrder object, right?

If method did receive the PendingOrder object, what object--from a best practices point of view--would be responsible for creating/finding the PendingOrder object to send to the updateDeliveryInfo() method? Would that be a Facade? Or would a Facade call some Application Service?

I guess I'm not clear on the purpose of a Facade vs an Application Service.

Thanks for shedding some light on this for me.
ceracm (113) [Avatar] Offline
Re: PlaceOrderService as Domain-Model Service
lili5058 ,

You raise an interesting issue.

I looked at page 105 of DDD. It says that the parameters should be "elements" of the domain model. Not sure whether elements = domain objects smilie. I quickly scanned the rest of the book and could not find clarification of this question. It raises a several issues such as who calls a repository to find an object by its primary key. etc etc. if the service can't take an id as an argument. It would also force you to add an extra layer into the code to retrieve objects by id and then delegate to a service just because a service was not officially allow to do that.

I think different books have different definitions of a service. e.g. Fowler's patterns of enterprise architecture shows services taking id parameters (page 139).

I think the key thing is to not get caught up in worrying whether something is a "true" service according to DDD versus PoEA vs ??. A better question is does the design work for you? Is it easy to understand? Maintain? Implement a coherent chunk of functionality.