You have several options, shown in order of increasing effort and degree-of-detail
- Create an (tabular) glossary of relevant business terms.
- Create an informal outline, where you show data types and their relationships. Define the terms in a glossary.
- Create a data or entity model (either as UML class diagram or Entity-Relationship diagram), where you show business entities with their attributes and relationsships. Define the terms in a glossary.
- Define a rich object model, where you add methods, functions or services to the entity model.
- Work according to the Domain Driven Design[^domaindriven]: Create a ubiquitous domain language with several bounded contexts, model business entities and aggregates, use value objects, services, repositories and factories to enable communication within and about the domain. Obviously this FAQ does not strive to provide detailed introduction to the fascinating topic of DDD, you have to look elsewhere (see below).
You should always define the meaning of the most important business terms in a glossary. Hopefully other stakeholders have already done that. Business terms are so easy to mis-interpret. You should make sure that does not happen within your system!
See also
- Eric Evans: Domain-Driven Design (Addision Wesley, 2004): The original source, 700+ pages of dense content.
- Vaugn Vernon, another veteran of DDD, has written “Domain-Driven Design Distilled” (Addision Wesley 2016), with only 170 pages - brief intro.