domain_driven_design.theory.txt

                        
   DOMAIN-DRIVER DESIGN  
                        



DOMAIN ==>                        #Sphere of knowledge

MODEL ==>                         #Set of related concepts inside a given domain
                                  #Often there are several models for a given domain:
                                  #  - e.g. different groups of users, legacy, etc.
                                  #  - should keep models separate from each other as much as possible ("bounded context"):
                                  #     - from any viewpoint: different UIs, APIs, databases, codebases, etc.
                                  #  - should be explicited using the "ubiquitous language"

VIEWPOINT ==>                     #Representation of the model from a point of view:
                                  #  - a category of people, e.g. end-user, developer, or different kinds of end-users/developers
                                  #    (owners, operators, etc.), or a specific organization
                                  #  - an aspect, e.g. security
                                  #  - a particular set of information
                                  #Possible sets ("architecture frameworks"):
                                  #  - Three-schema:
                                  #     - External: user view, e.g. database modelling
                                  #     - Conceptual: high-level developer view, that acts as a glue between two other views, e.g. database DDL
                                  #     - Physical: low-level, machine view, e.g. database implementation
                                  #  - 4+1 model:
                                  #     - Logical: functionalities (end-user)
                                  #     - Process: software dynamic
                                  #     - Development: software static
                                  #     - Physical: hardware
                                  #Must make sure implementation conforms to spec, and spec to business
                                  #  - should use continuous integration to ensure it
                                  #  - should use agile process to get constant feedback from users
                                  #     - should have domain experts available
                                  #When communicating (including commenting), must explicit which viewpoint is used (to avoid "ambiguous viewport")
                                  #Perspectives:
                                  #  - specific types of representation of a view
                                  #  - e.g. natural language, ER diagram, etc.

UBIQUITOUS LANGUAGE ==>           #Making all viewpoints share some wordings
                                  #As opposed to e.g. using viewpoint languages
                                  #Should be explicited

CONTEXT MAP ==>                   #Expliciting domain, models, bounded contexts