Encapsulating a database design into my domain design that is compatible with NHibernate

Question

Okay, I hope this makes sense!

I have an object Box which contains Items in it. The database design is such that only inserts are done on the Items table, and negative quantities are inserted to represent items being removed from the box. For example, if you put 10 items in the box, and remove 3 items, this would result in 2 rows in the Items table - +10 and -3. We use aggregate functions to get the true total, and there is a function to consolidate this table during quiet periods to avoid the table getting too big.

My initial thoughts on the domain model was to have an ItemsSet class which is a child property to the box, with ItemsSet having methods to manipulate and interrogate the collection of items.

The Box object looks something like this

public class Box
{
    public ItemSet Items { get; set; }
}

Here's a simplified example of what I was trying to achieve :-

var itemType = new ItemType("Bananas");
var box = BoxRepository.FindById(1);

box.Items.AddItems(itemType, 20);
Assert.That(box.Items.GetTotal(itemType), Is.EqualTo(20));

box.Items.RemoveItems(itemType, 5);
Assert.That(box.Items.GetTotal(itemType), Is.EqualTo(15));

I have to use my own methods because there is some domain-specific rules and checks done on the Add/Remove and GetTotal methods.

This causes a problem for NHibernate however as it uses its own internal implementation PersistentSet, which obviously cannot be cast to my custom type. I have to use the ISet (or ISet) interface, which means I lose my domain-specific methods.

Is there a way to get NHibernate to use my own collection, or am I better re-thinking my model and having an Items class, which maintains the items internally? What I'm basically asking is how should this database design be properly encapsulated in code that is compatible with NHibernate?