From 29b24e379661eaa14b95a3afc6c5f5f5b4202c44 Mon Sep 17 00:00:00 2001 From: trycatcher Date: Mon, 25 Mar 2019 16:55:25 +0530 Subject: [PATCH 1/2] Add a working definition of domain --- domain/DOMAIN.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/domain/DOMAIN.md b/domain/DOMAIN.md index 7daf884..5e2d5e1 100644 --- a/domain/DOMAIN.md +++ b/domain/DOMAIN.md @@ -2,6 +2,10 @@ ## What is the "domain"? What is a "model"? +- Domain modeling is the modeling of a domain of interest. Not a canonical, overarching domain but a subset +you are interested in. E.g. a seat can have numbers in a context that mandates assigned seating e.g. flight bookings +but not in another which does not e.g. watching a music concert; the domains differ even though they are dealing with +the same object i.e. seat. The domains differ because the contexts differ. - why have a model? - why prefer Value Objects? - how does good OOP mirror FP (or vice-versa)? From 04c56a9796822bf5bf1d412c10dbf0f2fea305e9 Mon Sep 17 00:00:00 2001 From: trycatcher Date: Mon, 25 Mar 2019 17:01:10 +0530 Subject: [PATCH 2/2] Elaborate on objects --- domain/DOMAIN.md | 1 + 1 file changed, 1 insertion(+) diff --git a/domain/DOMAIN.md b/domain/DOMAIN.md index 5e2d5e1..2273996 100644 --- a/domain/DOMAIN.md +++ b/domain/DOMAIN.md @@ -15,6 +15,7 @@ the same object i.e. seat. The domains differ because the contexts differ. - how is good OOP different from FP? - prefer fine-grained abstraction pushed to "leaf nodes" of the object hierarchy - avoid highly generic constructs + - objects are better thought of as Procedural Data Abstraction i.e. late-bound behavioral specialization triggered by receipt of a message through its public API. This is why it inter-object communication message needs to be as emphasized as the objects themselves. - [tbd - domain-v-model.jpg]