DDD-itsu

Ok I feel over my head here to start out with. Mostly because I have not done DDD on a project (well to its full extent).

There was debate over:

Account.depoit / account.withdraw
vs. A service implementation like:
WithdrawServier service = new WithdrawService(account)
service.withdrawAmount(100)

Which was an interesting debate but really comes down to implementation and complexity. Account.deposit/withdraw does violate SRP but on the other hand when you are modeling the domain I think you should be MODELING THE DOMAIN so an account can do deposits / withdrawls (IMHO)

The debate was expanded in more detail to this:
public class TransferService
{
  function Transfer(from, to, amount)
  {
       from.balance -= amount
       to.balance+=amount
  }
}

or

Public class Account

{
Transfer(amount, to)
{
    this.withdraw(amount)
    to.deposit(amount)
}

}

By doing the service method we have a lot more classes
by the account model the object is only dealing with another object of its same type

Or could have
Bank
{
      Transfer(account from, account to, double amount)
}

(but this starts to stretch the domain out past the aggregate root)

So all of these are right but easily debatable

Someone said that DDD is “Capturing ubiquitrons”.

“A diagram is the representation of the model”

We then moved on to defining some terms within DDD:

An entity is an object with identity and state

A value object does not have identity. i.e. currency (public class money) and are usually immutable

bob smith and bob smith are two different people even if they are wearing the same color of shirt. $5.00 and $5.00 are different bills but really the same thing and hence a value object. Address is another good example of a value object.

A cluster of entities is an aggregate: i.e. order and line item

Repository

Repository controls the retrieval of an aggregate root. Usually a few methods like findOne, findByQuery, handle saving of aggregates. There is usually one repository for each aggregate root.

Module

A module is an encapsulation. It may be that we model two separate things that do not interact (or interact minimally). This can be done with namespaces or separating them by assemblies.