Unit Testing Pure Domain Driven Classes

I am aiming to create a system which is based on pure domain driven design. As far as I am aware this means that my domain objects should have behaviour but not shape. That is, they should not have any getters or other accessors.

At the same time I am trying to follow TDD processes and have come across a stumbling block with a test I am trying to write.

[Test]
public class new_purchase_order_should_have_purchase_ordernumber_of_1
{
     PurchaseOrder po = PurchaseOrder.CreatePurchaseOrder()
     Assert.开发者_开发问答AreEqual(1,po.PurchaseOrderNumber); 
}

public class PurchaseOrder
{
       private int _purchaseOrderNumber;
       static CreatePurchaseOrder()
       {
           _purchaseOrderNumber = SomeWayOfGettingAPONumber()
           //other initialisation
       }

        public int PurchaseOrderNumber {get { return _purchaseOrderNumber;}
}

If getters are not allowed how do I verify that the CreatePurchaseOrder() methods functions correctly and sets a value of 1.

This is a big conceptual hurdle to me in trying to implement this design so any advice would be really useful.

Thanks

Why domain object can't have properties? Pure behavior you talk about, it is just static methods, they have nothing to do with Domain Objects.

The wikipedia tells us:

a business object usually does nothing itself but holds a set of instance variables or properties, also known as attributes, and associations with other business objects, weaving a map of objects representing the business relationships.

A domain model where business objects do not have behavior is called an Anemic Domain Model.

So, it turns, that domain object should have properties and (in most cases) behavior.

Martin Fowler says:

Domain Model - An object model of the domain that incorporates both behavior and data

One way to achieve this would be to follow CQRS ideas.

CQRS divides queries from behavior on architectural level (hence the name) and use domain model published events to expose state.

But it's quite hard to grasp and implement properly. Especially if You got no prior experience with domain driven design ideas in general.

Therefore - don't hesitate to expose state, just make sure it can be modified from object itself only.