330273 (1) [Avatar] Offline
#1
hi!

i have not yet gotten very far in the book yet, but i have to say i think the suggested application design includes some questionable choices and misunderstandable wordings.

the page numbers refer to MEAP v 11

* the ReleaseDate, Publisher and Developer tables are M:N tables designed as 2NF 1:N tables which guarantee data duplication. if a publisher publishes 2 games you will have 2 rows with duplicated text in the publisher table
* on page 18 it says that ReleaseDate is "Date in form of YYYY/MM/DD when the game was release for platform". dates in databases have no inherent format. this sentence suggests to save the date as a string which is bad design.
* page 30 refers to the domain model and then shows a class annotated with @Entity. database entities are not part of the domain model. the domain model is agnostic with respect to the storage technology being used and using entities in services is close coupling and thus bad design.
* even worse is the fact that the very same entity has a hand-coded convertToJson method which totally violates all best practices of clean architecture and SoC. why would a database object need to know how to convert itself into a format that only a resource needs?

i know this book is primarily about testing, but if people read books about microservices and are presented with such a design, they might repeat it and suffer the consequences.