From f1050f09d2d68777abc669415a0548020cd8ce03 Mon Sep 17 00:00:00 2001 From: Tom Hombergs Date: Tue, 17 Oct 2023 06:58:00 +1100 Subject: [PATCH] review comments --- README.md | 26 ++++++++++++++++++++++---- 1 file changed, 22 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 7caf396..844db61 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ ![Screenshot of the frontend](./docs/screenshot.png) -Sample for [Matthias Bohlen](https://mbohlen.de)'s +Sample for [Matthias Bohlen](https://mbohlen.de)'s [Domain-Driven Design class](https://mbohlen.de/domain-driven-design-cpsa-a/) (iSAQB Advanced Level). @@ -39,7 +39,7 @@ Finally, there is a frontend using React and Tailwind. Install Node. Then go to the root folder of this project here and type ``` -corepack enable +corepack enable # I had to run "npm install -g corepack" before this worked ... what is corepack for anyway? yarn yarn build ``` @@ -76,7 +76,7 @@ Done in 23s 8ms ``` cd packages/database docker-compose up -d -sleep 30 +sleep 30 # this sleep is very suspicious. Can you explain it? yarn knex migrate:latest ``` @@ -89,6 +89,8 @@ docker-compose up -d ### Start the API servers +# Oh, so each "package" has its own (Express) server? That is very strong decoupling between the (sub)domains at the cost of some developer experience because now I have to start each server on its own. Maybe document the tradeoffs this architecture makes somewhere? + 1) Open a new terminal and type this: ``` @@ -119,7 +121,9 @@ yarn dev ### Start the reverse proxy -Install [Caddy server](https://caddyserver.com/) on your local machine. +Install [Caddy server](https://caddyserver.com/) on your local machine. + +# Another thing I have to do because each (sub)domain has its own webserver... On a Mac, using Homebrew, it works with `brew install caddy`. @@ -176,3 +180,17 @@ yarn test ``` Terminate the test with the `q` key on your keyboard. + + +# Tom's verdict: +# I find the structure of the code very understandable, it could have come from my book :). +# However, the dev experience feels more like working with microservices than working with DDD +# because each module has its own webserver. That's not bad per se, but it opens the architecture +# to an attack vector like "Why do I have to start 4 web servers during development? That's way too +# much effort!". It feels like overhead for a small application like this (but then again, example +# applications are always small). Maybe think about documenting some architecture decisions in the README +# that show the tradeoffs you made when coming up with this architecture. That makes it clear that +# this is not the "one architecture" everyone must follow, but that it's just one form of a DDD +# architecture that was chosen because of certain reasons. + +# The code and structure is clear, the application works locally.