A customer should be able to view its past orders, along with their dates and chosen products. This is necessary so that clients can view a single piece and request an arbitrary amount of it again.This piece of documentation seems to have been written by a poor analyst. It is also the first break in the chain between the user needs and the programmer understanding of the business domain.
A common practice in agile development is incorporating the final user in the process, even to the point of substituting the analyst with a programmer. In fact, in Italy one of the few things that works well is the small size of software firms, which eliminates communication overhead. One time we were able to get a vacation packages selling system up and running in a day, tailoring it in real time to the adjustments provided by the customer.
However, in every serious project a written set of requirements is necessary, to serve as an analysis of the domain and as future documentation. But formal language is not a sole property of php code: Italian, English and other languages can be used in such a way to define without ambiguity the concepts and the functionalities of a domain model. Communication is the major issue in software design and this issue should be addressed accordingly: by defining an higher-level language over the natural tongue.
Let's walk through some steps to transform the sample initial analysis in an instance of Ubiquitous Language, that captures information from the domain.
We will make additional hypotheses on the requirements and the model because we do not have a user of the application available here we can ask questions to. This process should be conducted in the original requirements gathering and initial modelling phase.
Synonyms are the most powerful enemy of an Ubiquitous Language: different domain concepts should be named differently and coincident concepts should be named equally. This practice promotes consistency and predictability in documentation and then in the produced code.
The names of concepts are usually written capitalized, to highlight their special role in the prose. They often become class names, so the capitalization is a suited trait. Anyway they will find their place in the domain layer or be eliminated while refactoring.
Once grasped, the practice of using Ubiquitous names will become a second skin, and you'll find yourself making questions such as "We are talking about this data as associated to a particular Customer?" and "So a Customer can make many Orders and an Order should have a unique Customer?" all the time.
A Customer should be able to view its past Orders, with their dates and chosen Products. This is necessary so that Customers can view a single Product and request an arbitrary amount of it again.
Look at the available operations and see how they can be better described by involving the Ubiquitous Language.
A Customer should be able to find its past Orders, with their dates and chosen Products. This is necessary so that Customers can view a single Product and create a new Order associated to it.
Maintain the Ubiquitous language in sync with the refactoring of the domain concepts, and let it evolve with the code.
Contuinuing with the example, let's say the customer asks for a refinement: only some products are available for shipping, while others are difficult to send and they should be "retired" at a particular warehouse. Here's another piece of description that involves the Ubiquitous Language and describes these additions.
"A Product has a Delivery relationship, which may be a Shipping or a HandOver. A Delivery is always a property of the single Product and it exhibits traits such as a description and its availability in time."I hope this panoramic of the Ubiquitous Language concept will be helpful in improving your human language usage in documentation and communication with users and other developers; your goal should be to convey concentrated, distilled knowledge.
If you have any suggestion to expand on this topic, feel free to add a comment.