Using return value instead of waiting for messaging back

[Samuel Abiassi]

I'm trying to model a use-case where a Customer is booking a train ticket.

At one point, the sales person needs to check if seats are available in the train. In my mental model, they do so by asking the Logistics service if said seats are available.

Here is how I wrote it:

// Operator role

... [checkSeatsAvailability]: (numberOfSeats: number) => {

      if (LogisticsService[confirmSeatsAvailability](numberOfSeats)) {

        updateJourneyInformation('seats', [{ seatNumber: 34, trainCar: { id: '34', name: '34' } }])

        Operator.askForBookedJourneyConfirmation()

      }

    },

...

// LogisticsService role

...

[confirmSeatsAvailability]: (numberOfSeats: number): boolean => {

      return LogisticsService.checkSeatsAvailability(numberOfSeats)

    },

...

My question is: is it okay to "message back" by using a return value or is it a bad idea?

[James O Coplien]

Looks fine.

In trygve, the ticket would be a StageProp.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/d8b9b7f4-ed14-4e53-8008-5a5d4813a92cn%40googlegroups.com.

[Samuel Abiassi]

Another question on the same example.

Here, I used a checkSeatsAvailability method provided by the LogisticsService object.

I guess this should have been a new SubContext instead?

[Matthew Browne]

I guess this should have been a new SubContext instead?

Probably yes... LogisticsService sounds like a context to me. The question to ask for contexts is (at least in traditional DCI), what use case is it fulfilling? If the use case is "Check Seats Availability", then maybe that should be the name of the context instead of LogisticsService. And if LogisticsService is also doing other things that belong to other use cases, then you might need to separate it into multiple contexts.

But this is all conjecture at this point...the use case design should inform the code rather than the other way around. Depending on what checkSeatsAvailability is doing and where else it's needed, maybe all of that logic could just go in your main context for booking a ticket, as long as it's organized into roles.

To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/99f60f37-6d43-45d7-8933-b18a000e440en%40googlegroups.com.

[James O Coplien]

On 2 May 2024, at 18.04, Matthew Browne <mbro...@gmail.com> wrote:

Probably yes... LogisticsService sounds like a context to me.

It sounds like a catch-all to me…

When I think Context, I want to think use case. I’m having difficulty making the leap.

[Samuel Abiassi]

My main scenario for the "booking a train" use-case looks is obviously uninformed and a partial attempt, as I'm lacking domain knowledge and the use-case volontarily omits payment: 

# Use Case: Customer Booking a Train

Actors:

Customer: The individual or organization who wants to book a train ticket.

Sales operator: Company's outward facing service that is responsible of selling tickets to customers.

Transit service: Company's internal service that is responsible of choosing which trains will transit.

Internal Logistics: Company's internal service that's responsible to maximize the used seats in each trains.

Sales service: Company's internal service that's responsible for registering booked tickets

Preconditions:

The customer has access to the train booking platform or application.

## Main Success Scenario:

1 - Customer emits the need to take a journey to the train Operator.

2 - Train Operator asks the Transit service which stations compose the national network.

3 - Transit service provides a list of all the national network stations to the Train Operator.

4 - Train Operator proposes multiple starting points, destinations, and a date to book the train to the Customer.

5 - Customer selects a starting point, a destination, and a date, and communicates them to the Train Operator.

6 - Train Operator asks the Transit service which trains are transiting from the starting station to the ending station on the specified date.

7 - Transit service provides a list of the trains corresponding to the aforementioned criteria to the Train Operator.

8 - Train Operator proposes these next bookable trains to the Customer.

9 - Customer selects a train between the proposed options and communicates her choice to the Train Operator.

10 - Train Operator asks the Customer how many seats are needed.

11 - Customer answers the Train Operator with the number of required seats.

12 - Train Operator asks the Logistics if the chosen train has the number of required seats.

13 - Logistics confirms that the number of required seats is available to the Train Operator.

14 - Train Operator confirms the availability of the booking to the Customer.

15 - Train Operator sends the booking information to the Customer for review.

16 - Customer reviews the final information and confirms the booking to the Train Operator.

17 - Train Operator sends booking information to the Sales service for registration.

18 - Sales service confirm the registration has succesfull to Train Operator.

19 - Train Operator confirm the registration to Customer.

The volume of this scenario obviously make me think that it should be divided in more coherent and digestible parts.