public IEnumerable OrderLines
{
get { return _orderLines.Select(o=>o); }
}

Will return only the IEnumerable and casting will return an InvalidCastException. Also, you get the advantage of deferred enumeration. Loading the Enumerable into a ReadOnlyCollection, immediately iterates over the entire list.

Here’s the test I wrote just to make sure I wasn’t in the threes:

[TestFixture]
public class OrderTests
{
[Test]
public void OrderTotalIsNotEncapsulated()
{
var order = new Order();
var orderLines = new List(order.OrderLines);

orderLines.Add(new OrderLine(1));
Assert.AreEqual(0, order.Total);
}
}

class Order
{
private List _orderLines = new List();
private double _orderTotal;

public IEnumerable OrderLines
{
get { return _orderLines; }
}

public double Total { get { return _orderTotal; } }

public void AddOrderLine(OrderLine orderLine)
{
_orderTotal += orderLine.Total;
_orderLines.Add(orderLine);
}

public void RemoveOrderLine(OrderLine orderLine)
{
orderLine = _orderLines.Find(o => o == orderLine);

if (orderLine == null)
return;

_orderTotal -= orderLine.Total;
_orderLines.Remove(orderLine);
}
}

class OrderLine
{
public OrderLine(double total)
{
Total = total;
}

public double Total { get; private set; }
}

It think this breaks the Single Responsibility Principle. I would rather have an OrderService to handle the business logic and add up the total. This way the order collection would be lighter to carry around or reuse on other layers. I personally don’t like to embed business logic into entities (or their collection) to keep the domain simpler.

I like to see entities as simple documents an nothing more. But of course this approach is still good and I guess it is just a personal choice.

Here’s a quote from Domain Driven Design Quickly: “The verbs of the language, associated with their corresponding nouns become the part of the behavior of those objects. But there are some actions in the domain, some verbs, which do not seem to belong to any object. They represent an important behavior of the domain, so they cannot be neglected or simply incorporated into some of the Entities or Value Objects. Adding such behavior to an object would spoil the object, making it stand for functionality which does not belong to it. Nonetheless, using an object-oriented language, we have to use an object for this purpose. We can’t just have a separate function on its own. It has to be attached to some object. Often this kind of behavior functions across several objects, perhaps of different classes. For example, to transfer money from one account to another; should that function be in the sending account or the receiving account? It feels just as misplaced in either.”

I am not a design guru so I might be taking this principle a bit too far. What do you think about it?

I really enjoy your posts, I came across your blog before and I think you are a good good writer. I will follow this series for sure!

It think this breaks the Single Responsibility Principle. I would rather have an OrderService to handle the business logic and add up the total. This way the order collection would be lighter to carry around or reuse on other layers. I personally don’t like to embed business logic into entities (or their collection) to keep the domain simpler.

I like to see entities as simple documents an nothing more. But of course this approach is still good and I guess it is just a personal choice.

Here’s a quote from Domain Driven Design Quickly: “The verbs of the language, associated with their corresponding nouns become the part of the behavior of those objects. But there are some actions in the domain, some verbs, which do not seem to belong to any object. They represent an important behavior of the domain, so they cannot be neglected or simply incorporated into some of the Entities or Value Objects. Adding such behavior to an object would spoil the object, making it stand for functionality which does not belong to it. Nonetheless, using an object-oriented language, we have to use an object for this purpose. We can’t just have a separate function on its own. It has to be attached to some object. Often this kind of behavior functions across several objects, perhaps of different classes. For example, to transfer money from one account to another; should that function be in the sending account or the receiving account? It feels just as misplaced in either.”

I am not a design guru so I might be taking this principle a bit too far. What do you think about it?

I really enjoy your posts, I came across your blog before and I think you are a good good writer. I will follow this series for sure!

Thanks I was not aware of what the events args were of OnCollectionChanged. That said I still find the contract of the aggregate to be much cleaner and more explicit with the Add Remove methods. In fact if this were in my Domain I would probably even new up the OrderLine Item as part of the method instead of having it passed in as an argument.

My Aggregate might start like
http://www.codepaste.net/kho2qm

and then later evolve in many different directions including moving to a write only model or adding back references on your internal representation.

http://www.codepaste.net/n1no9o

It seems to me that this is a case where by being explicit in your contract, you can evolve many more directions while still maintaining the same external contract than what you gain by violating Dementer (I know there are often good reasons to violate Dementer, but I am not sure what they are here.) What is it we gain by exposing and observing the collection. I started down that path once and wrote a few list Decorators that provided On Insert, After Insert, etc… to Existing ILists.

The problem is that decorating the list and wiring up your event handlers was not much if any less code and when your object evolved and you wanted to change your internal representation of the collection(like to a “write only model” like above), you had to change all your calling code or write a bunch of biderectional synchronization code and events.

Often times 1 refactoring can lead to another. You might make the first refactoring above and then you think Why do my callers have to know how to construct an orderline. Let’s fix all the places I am newing up an orderline before this gets out of hand.

The calling code goes from

var order=OrderProvider.GetOrder(OrderID);
var orderline = new orderline (Order,itemType,qty);
order.Orderlines.Add(orderline);

to

OrderProvider.GetOrder(OrderID).AddItems(itemType,qty);

and has fewer reasons to change. To me this is a good thing.

Thanks,

Erik

And theres no digging, the collection simply pushes observable events when items are removed or added.. and no you wouldn’t need to enumerate the list, you get an enumerable of added / removed items in the event args (to support mass adds / removes).

Remembering the main reason these methods exist AddX vs X’s.Add is purely by a limitation that there weren’t great ways to add policy or observation in from the aggregate.. it isn’t something thats desirable..