当作用域对象而不是作用器时，如何使用方法表示域对象的行为？

Question

In Domain Driven Design, there is an emphasis of placing behaviors where they correctly belong. I'm not always sure what exactly constitutes "correct," though.

Consider this scenario:

Grammatically, we have that:

• 'client' is a

• 'withdraw' is a

• 'amount' is a

• 'account' is an affected

Classically, the client would execute this: .

This could be read as: However, this does not grammatically correspond to the original scenario, since 'bank account' is now the and an removes 'withdraw' and 'amount' from the main clause so that the primary idea conveyed is that 'client commands account'.

To adhere to DDD, we should regard this code as precisely describing the original scenario. This implies that the 'withdraw' method does not model a behavior the account (the account is not a ), but rather it models a behavior that it (the account is a ) and could very well be renamed 'wasWithdrawnFrom'. Moreover, the method argument represents something being affected as opposed to (it is a for , not ).

If we extrapolate from this example, we can see that methods may represent and method arguments may represent .

However, whether or not methods should represent is unclear.

So my question is:

Answer 1

You seems to be stuck in a theoretical thesis. I'm not sure you can apply a theory that works for every scenario/project. Behaviors usually appears when you start bombarding your Model with Use Cases. I try to let the cases dictate behaviors. To follow your example:

Actor Customer want to withdraw money from Account. The way to do it is like you do Account.Withdraw(Money amount)

But your question "How should we use methods to model object behavior?" is a common DDD question. How to enrich your model with behavior? My best hints is to find your Value Objects. Value objects usually comes with behavior.

In example Account is and Entity (Aggregate root probably). Money (Value object with Currency and Amount) should be withdrawn from an Account. That should be Account Single Responsible (Principle) to control that Account balance and all access to it. Regarding your (2) question in the end. Methods are absolutely used for change the objects inner state. But when it comes to behaviors performed by the entity/value object like Customer.Order(newOrder) or advert.Apply(candidateCV) we can make entities communicate with each other. We can also create chained behaviors through Domain Events which can help us not to leak to much business logic to our application services. See Udi Dahan's blog for that or my blog article regarding Anemic Domain model http://magnusbackeus.wordpress.com/2011/05/31/preventing-anemic-domain-model-where-is-my-model-behaviour/

I Hope you got some ideas. It's difficult to give concrete hints when we are so abstract here. /Best regards Magnus

Answer 2

I find that scenario too simple to be real, hence too simplistic to model too. I would reformulate the

"The client withdraws an amount of money from a bank account."

to something like

"The client submits withdrawal request of value xxx $ from his account" (when I go to my bank I have to fill out a form in order to withdraw money where I state amount, the account number, date and my signature)

There one can spot a request ( command ) to a service ( withdrawal service ) of an client ( client identified by ID ) from his account ( account identified by ID ) and the money value ( money as value object ).

Answer 3

I don't care much about the grammar, as English is my second language so when trying to understand the Domain, I try to understand how the business sees the concepts (Account) and workflows (withdraw an amount) and not to do grammar analysis.

The point of DDD is to model things like they are in the business, so behaviour shows up according to Domain understanding.

in this scenario, for me it's clear that we're working within the Account Operations Bounded Context and at least the Account aggregate root is involved. Of course, in banking terms, probably (I'm guessing here) there will not be a withdrawl but an operation to increase the Debit/Credit part of an account, so most likely the account will register that a debit/credit operation has happened. And a Domain Event is born and published. Then let the domain expert tell you what will happen next.

"The client deletes an order" => order.delete

Probably the order is never deleted, but its status will changed to 'canceled' or similar. However for that case when an order really should be deleted, the order doesn't delete itself, the Orders repository deletes that order.