User Stories and Objects in OOP

Last year I wrote an article for InfoQ where I shared my guesses about commonalities between SOA, XP and OOP. Recently it struck me how much user stories and objects particularly have in common.

First of All, the User Story Is an Object

Just like anything else. My user story interface looks like that:

interface UserStory
{
    public function response(): Response;
}

My ideal user story looks like a set of declarative decorators with a single return statement: some basic object is decorated until the desired behavior stated in a form of acceptance criteria is reached.

Let’s consider an example from the food industry. A customer sends an order registration request to my service via an app or a browser. There are a number of things that should be done. First of all, the nearest restaurant where an order is to be delivered from must be calculated. Then an order should be persisted in a database, and after that, it should be sent to a restaurant. Those steps are behaviors specific to certain objects, each of which represents a certain aspect of an order to be registered. So my first move is to create an interface:

interface OrderToBeRegistered
{
    public function register(): void;
}

It is an abstraction defining what is about to happen. Concrete classes implementing that interface are my hows. Their composition could look like the following:

(new WithRestaurantNotified(
    (new Persistent(
        $orderId,
        $this->dbConnection,
        new WithCalculatedRestaurant(
            $orderRegistrationRequest
        )
    )),
    $this->transport,
    $orderId
))
    ->register()

This is the crux of my RegisterOrder user story.

Besides, user stories themselves are decoratable. The most typical case is a separate user story where validation takes place, and a separate one where business logic is carried out.

So my user story is just a composition of more lower-level domain-specific objects.

Encapsulation

Both the user story and an object hide implementation details. Just like objects talk to each other via sending messages (invoking each other’s methods), user stories communicate via domain events. Besides, both user story and object facilitate to be reasoned about when having an appropriate (that is, small) size and having descriptive names resonating with the real world and real business-processes.

This holds true for objects of any size by the way: domain-specific objects, user stories, business services, and organizational units that follow Conway’s Law.

Interfaces and Acceptance Criteria

Acceptance criteria summarizes what a user story is all about, what effect it has. The same goes for interfaces: ideally, they declaratively state what the object’s behavior is, which is reinforced by unit tests.

Units Tests and Definition of Done

Just like there is a list of properties that completed user stories possess, all objects have at least one such item, which are unit tests.

Waterfall and Procedural Programming

In the same way, I believe there is a lot in common to waterfall and procedural programming. Waterfall exposes its implementation details of each and every phase to the next one, while procedural programming effectively does the same: a set of procedures (phases, or services) acting on data.

Everything Is an Object

Just to reiterate, object is a very lively and proven concept, because it belongs to the real world. It’s not an invented one, it’s a discovered one. It manifests itself virtually in any level and aspect, even on the atomic level, with atoms being an encapsulated objects, human beings, organizational units, states. And it’s only natural that fifty years ago it was first employed at Xerox PARC to give birth to the first and the only pure object-oriented language.