Class Methods play a pivotal role: they let you invoke domain logic explicitly tied to an entity. Methods appear as action buttons in the explorer:

Following standard .NET scoping rules, only public methods are visible.

When the action button is clicked, the method is executed immediately. No results are shown in the UI, but a message notification appears, and a message is added in the Message Panel.

If the method returns a primitive value, the result is shown in the Message Panel.

If the method returns an object, the result is shown in a new Explorer panel. You can explore and navigate that object just like any other.

When the button is clicked, a dialog appears with placeholders for the parameters:

After the parameters are provided, the user can click the Execute button to run the method.

In some cases, a method may require an external dependency (for example, a complex computation that has various rules). If a method has a parameter of the same type as the dependency, that dependency will be injected in.

In the following example, our ShoppingCart class has a method that accepts an OrderBuilder parameter:

/// <summary>
/// Places this order
/// </summary>
/// <param name="orderBuilder">The domain service that creates an Order</param>
/// <returns></returns>
public Order ConfirmAndPlaceOrder(OrderBuilder orderBuilder)
{
    var newOrder = orderBuilder.CreateOrder(this);
    return newOrder;
}

Clicking the “Confirm And Place Order” button would execute this method immediately, without prompting for a value.

Note that dependencies can be mixed with regular parameters. In the following example, the orderBuilder is injected automatically, but you would be prompted for the placementDate value:

/// <summary>
/// Places this order
/// </summary>
/// <param name="orderBuilder">The domain service that creates an Order</param>
/// <param name="placementDate">Used to override the date of the order</param>
/// <returns></returns>
public Order ConfirmAndPlaceOrder(
    OrderBuilder orderBuilder, // 👈
    DateTime? placementDate)
{
    var newOrder = orderBuilder.CreateOrder(this);
    if (placementDate != null)
    {
        newOrder.PlacementDate = placementDate.Value;
    }
    return newOrder;
}

Using clearly defined dependencies improves the overall domain model, which in turn builds a richer ubiquitous language.

Sometimes, a method may be semantically related to a specific property. You can reflect this in the UI, like so:

/// <summary>
/// A read-only string property
/// </summary>
public string A_String { get; private set; }

/// <summary>
/// Used to set the string
/// </summary>
/// <param name="newValue"></param>
[Method(RelatedPropertyName = nameof(A_String))] // 👈 This will render the method button under the A_String property
public void Set_A_String(string newValue)
{
    A_String = newValue;
}