Let's dig a bit further into one of the Bounded Contexts. Take, for example, the Orders context and examine the structure details. As its name suggests, this Bounded Context is responsible for representing all the flows that an order passes — from its creation up to delivering to the customer who has purchased it. Furthermore, it's an independent Application, so it contains a source code folder and a tests folder. The source code folder contains all the code necessary for this Bounded Context to work: the Domain code, the Infrastructure code, and the Application layer.

The following diagram should illustrate the organization:   

                 

All the code is prefixed with a vendor namespace named in terms of the organization name (BuyIt, in this case), and contains two subfolders: Domain holds all the Domain code, and Infrastructure holds the Infrastructure layer, thereby isolating all the Domain logic from the details of the Infrastructure layer. Following this structure, we're making it clear that we're going to use Hexagonal Architecture as a foundational architecture. Below is an example of an alternative structure that could be used:

                         

The above style of structure uses an additional subfolder to store the Services defined inside the Domain Model. While this organization may make sense, our preference here is to not use it, since this way of separating code tends to be more focused on the architectural elements rather than the relevant concepts in the model. We believe this style could easily lead to some sort of Service layer on top of the Domain Model, which isn't necessarily a bad thing. Remember that Domain Services are used to describe operations in the Domain that don't belong to Entities or Value Objects. So from now on, we'll stick with the previous code organization.

It's possible to place code directly inside the Domain/Model subfolder. For example, it may be customary to place common interfaces and Services, like the DomainEventPublisher or the DomainEventSubscriber, in it.

If we had to model an Order Management context, we'd probably have an Order Entity with its Repository and all the state information. So our first attempt would be to place all those elements directly into the Domain/Model subfolder. At first glance, this may seem like the simplest way: