What types of written project documents are used in DDD projects?

Question

1. Which of the following types of written project documents do we usually use in DDD projects:

a. Document Specification Requirements

b. A document explaining the meaning of the main elements.

with. A document giving a bird's eye view of the application structure

e. A document explaining the meaning of the terms used by the ubiquitous language

e. Document containing Ubiquitous Dictionary

f. Unofficial UML Charts

anything else?

2. What types of documents should be created as stand-alone documents and which should be combined in one document (example: a document containing diagrams surrounded by text)?

3. And what are the specifications of the requirements? A list of use cases, a task list of a program can perform or combine both?

thanks

Answer 1

Consider the following:

• Approving your app’s goal in 25 words or less
• Representation of your model both in code and in uml
• List of features matching the current or desired model
• List of constraints (business rules) for the model
• If necessary, a sequence diagram for each function
• Disabled Claim Statement
• Architectural overview for team members (including model boundaries and contexts)
• Team instructions and procedures

Note: use cases or user stories may inform your feature list. However, I recommend that the function be a unit of work.

I recommend that an initial model be created (discovered) at a modeling workshop in which both domain (business) specialists and developers participate. It should be led by someone with domain modeling skills.

Business rules are restrictions for a model of two types: Property and Collaboration. For example, business rules prevent an elevator from moving an open door, a perishable item in an uncooled bin, or a delayed purchase.

Answer 2

I think Event Storming might be a good solution. Photo workshop should be enough. If not, you can use the same artifacts in a digital document.