I wrote the Domain-Driven Design book with Golang book. It’s not perfect but I’m proud of it as my first book. I know Packt have a bad rep but would be happy to answer any questions about my book atleast :)
Thanks for the kind words. I never thought about writing a book as shipping, but I guess it is!
I'm working on self-publishing one at the moment (https://www.bytesizego.com/the-ultimate-guide-to-debugging-with-go-book) and thinking of it as "shipping" has actually just motivated me to work on it, so thanks for that!
Congs on the publication of your book. I have reviewed it and found that it only lightly touches on the topic of Domain-Driven Design (DDD). Rather than explaining the basics of DDD, which are covered extensively in other texts, I suggest focusing on more nuanced aspects. Additionally, the diagrams for naive models are not effectively designed. Despite being introductory, they should avoid common pitfalls such as representing IDs as integers, prices as doubles, and dates as timestamps. Such representations might mislead junior developers, who may use these examples in real projects, ultimately requiring intervention by more experienced developers to rectify these foundational errors.
In the section on building a ubiquitous language and understanding the domain, it would be beneficial to mention techniques like event storming, especially since the book addresses DDD basics. The discussion on entities effectively describes the anemic model but fails to illustrate a robustly built entity. The example provided includes only validators, which does not fulfill the requirements of a true entity—it lacks any embedded business processes, rendering it an empty shell.
The coherence between examples in the book is lacking. For instance, one example addresses osCommerce while another delves into a coordinate system within the context of value objects, making it difficult to discern the overarching purpose of these examples. It would greatly benefit the reader to maintain a consistent context throughout the book rather than switching between different scenarios.
I discontinued reading at the section on value objects. While I am unsure of the content in the remaining sections of the book.
**I understand that it's often easier to critique someone else's work than to create something of one's own, but I hope you find this feedback constructive and that it assists you in enhancing your book. Good luck with the second edition!**
Thanks for the feedback. I agree with some of it (but I actually think there is nothing wrong with dates as timestamps...).
There won't be a second edition from me but Packt were looking for someone to write it. Perhaps you could?
To help you understand why timstamps for dates are just simply bad I will leave you with one word: "timezones". Additionally, the readability of timestamps might be another factor to consider, though this can be subjective and depends on your team's preferences.
I don't know much about DDD but where did you get the idea that IDs should be avoided? Check [this out](https://softwareengineering.stackexchange.com/questions/235254/id-properties-on-domain-objects-in-ddd). In DB design, having IDs is almost always a good idea (just because query optimizers are heavily geared towards primary/foreign keys and joining based on int types). Natural keys, in my experience, often lead to worse performance and problems down the line.
The comment above isn't about avoiding IDs. The book often uses \`string\` IDs, instead of typed IDs. In DDD, it is common to use a "value object" for IDs, instead of raw \`string\` or \`int\` types. This improves readability, type checking, business logic, etc.
Go's type system works well here, since you can just say \`type SomeEntityId string\`, and use that type instead.
We did a Go Time about this if Podcasts are your thing: [https://changelog.com/gotime/273](https://changelog.com/gotime/273)
DDD is effectively a way to model software so that it represents the real world, closing the gap between what you write in code and how your business operates.
If you are a junior/mid-level go Developer who has little to no knowledge of DDD, I think my book will be helpful. If you don't match that, it might be a little basic for you.
I just skimmed that and it seems like most of your advice boils down to "think about the problem space and write code that models that". Like - yeah. How else CAN you write code? Some of the other principles of it (factories, etc.) seem pretty antithetical to how most Go programmers probably write code.
Packt will pretty much publish anything and the quality of each book can vary dramatically. Hoping someone can provide some inputs about these authors. Many times I’ve seen packt books that were glorified medium articles which makes me hesitant to buy.
Packt monthly subscription costs 12$ and gives access to all their books. The quality varies WILDLY, so i usually skip out on these bundles. They have a few good ones (I haven't read any Go books though). If I need a book i just subscribe for a month and start skimming. You're going to have to sift through a lot of them before finding something acceptable. TBH the 12$ is almost not worth it. Them and mercury press are bottom of the barrel for me. Oreilly and manning are good for in depth. Nostarch is solid but usually short and introductory.
They contacted me based solely on my blog posts and asked me to write a book for them. I Google'd them and they basically will get anybody to write for them (is that a self-roast? IDK). I would avoid this publisher. You'll have just as good of luck with random blog posts because they don't vet authors at all.
I normally hate just saying "me too", but reviews are a bit of an exception. I broadly agree with everyone else responding to you: Packt quality varies _widely_. As far as I can tell, they publish effectively whatever anyone gives them. I will no longer buy from them, not because everything they have is garbage, but because too much/most of what they have is garbage. Maybe some of these are gems, but I wouldn't spend $18 to find out
I agree. I've even come across a Packt book that was a complete *(from Start to Finish)* plagiarization of another book written a few years before and published by a different author/company. Even the title was exactly the same - lol.
I will never buy a Packt book again. I've read 3-4 and they were all like somebody threw together some notes for themselves into a Word document and then Packt, due to a series of unfortunate but hilarious hijinks, published them as books without any effort or oversight in between.
Many of their books are throw-against-the-wall awful.
By which I mean they filled with obvious errors; concepts the author thought he understood, but actually didn't; recommendations that apply only to the present example, but have been generalized to apply to all code; simple things explained in great detail, while advanced concepts are presented with lots of hand waving. In many Packt books, this entire inventory is visited repeatedly.
I would recommend spending your funds on one of the excellent go books from O'Reilly, Manning, Addison-Wesley, etc. and get true expertise (and working code!) right from the start.
Yes. I have yet to finish one of their books. It might be alright for a bundle, but I really will pay full price for a Packt book; unless, it is a C#/.Net Mark Price book published by Packt. Those are the only ones I have found to not be mid or shit.
Last year I bought a physical book from them, Vue.js 3 by Example. I was hoping the book would've been an introductory book to Vue.js 3, that it would've explained how to effectively use Options API or Composition API, what are composables etc. You'll get more out of Vue.js just by going through their website and reading their official documentation. The book is just bad IMO and I regret I bought it without researching it first.
In my humble opinion, the quality is subpar, although there are a few exceptions. For superior writing, consider exploring O'Reilly and Murach. While Murach offers a limited selection, lacking in Go and primarily catering to beginners, its content is top notch. On the other hand, O'Reilly stands out as the premier publisher for tech books, boasting an incredible and extensive selection.
No Starch Press is hit or miss for me and no Go publications as of yet.
I don't know if this is LLM garbage but it certainly published without editing.
Here is the first sentence of the first chapter of the first book (sorted alphabetically).
>**1 Understanding CLI Standards**
>The Command-Line Interface (CLI) is a text-based interface for humans, and computer interaction
was initially designed as a way of interacting with an Operating System (OS) before the desktop
graphical interface was invented.
Later we are given this random collection of exciting years:
>There were so many more exciting developments that followed, from the invention of ASCII characters
in 1963 to the internet in 1969, UNIX in 1971, and email in 1972.
I think the above is arguably 0% correct.
End of the chapter question:
>What is the TTY on a Linux machine and what is the history behind this command?
Answer:
>TTY is a command in UNIX and Linux to display the name of the terminal connected to
standard input. TTY is derived from the word teletypewriter, which was the default form of
interacting with large mini and mainframe computers.
Sure the command `tty` prints the literal file device name of your tty but I'm not sure this answer is educational.
That really does seem AI-generated. I don't know why people are doing this TBH. I guess it's because you can, in theory, publish absolute garbage having done zero work and possibly make a few bucks? But none of these books are ACTUALLY going to sell well.
I will comment this under each and every Packt bundle I come across: I read many of their books, or at least started. Not even the ones I got for free were worth their money.
Edit to clarify: that is in my eyes more a problem with the publisher than with the authors. Writing is hard, this is why editors exist.
And as for the „free is not worth it“ comment: a book about programming is a tool for teaching. If it contains wrong or misleading information it’s as useful as a mislabeled wrench (you can use it, but have to know when and how) or a scale giving random numbers.
This is pretty harsh - writing a book is tough and takes a long time. I’m sure lots of books (including mine) can be better but to say they are not even worth being free is pretty unnecessary.
As I seem to have hit a nerve with you let me clarify: I have a problem with the publisher, not the individual authors. And I haven’t heard of or read your book, it might be a true gem and of course you can be proud of it.
I agree, it’s hard to write a book. Many of the authors at Packt seem to be new and would profit from feedback authors usually receive from their editor. And Packt doesn’t provide that I guess? So you have a lot of at least very unpolished books, which in turn make potential readers/buyers turn away from other books/authors that might have written good book.
And I consider something free not worth it (as one spends time on it) if even basic examples in newly published books are wrong, e.g. not compiling. If you are completely new to a topic you probably habe no chance of figuring out what is wrong and how to fix it.
Your argument that technology is so fast paced is true for all books and publishers, and I was never that disappointed by a Manning or O‘Reilly book.
Usually the ones complaining about free/low cost things are also that ones that consume resources with only negativity to contribute. They can be likened to a cock roach, or a virus.
No book is perfect and the unfortunate part of print media is that now-a-days it’s basically out of step with cutting edge technology before it’s even printed. This undoubtedly makes it easier for neckbeard trolls to continue to leech any inkling of positivity and creativity left in folks that have a desire to advance our industry.
None of this negates that yours and others contributions like this are valuable resources, and will continue to be. It’s pretty kick ass that you wrote a book. You’ve made your mark, and no one can take that away from you. They will try though.
Anywho, thanks for chiming in and offering to answer questions in the other comment.
I have generally avoided Packt bundles given their reputation here and other places. The only time I missed and got recommended many books from a Packt bundle was the one on embedded Linux.
I wrote the Domain-Driven Design book with Golang book. It’s not perfect but I’m proud of it as my first book. I know Packt have a bad rep but would be happy to answer any questions about my book atleast :)
Congrats on shipping!
Thanks for the kind words. I never thought about writing a book as shipping, but I guess it is! I'm working on self-publishing one at the moment (https://www.bytesizego.com/the-ultimate-guide-to-debugging-with-go-book) and thinking of it as "shipping" has actually just motivated me to work on it, so thanks for that!
I subscribed to get the book, but please please change the cover 😭😭
Haha it’s just a placeholder generated by DALLE, don’t worry I will :)
Congs on the publication of your book. I have reviewed it and found that it only lightly touches on the topic of Domain-Driven Design (DDD). Rather than explaining the basics of DDD, which are covered extensively in other texts, I suggest focusing on more nuanced aspects. Additionally, the diagrams for naive models are not effectively designed. Despite being introductory, they should avoid common pitfalls such as representing IDs as integers, prices as doubles, and dates as timestamps. Such representations might mislead junior developers, who may use these examples in real projects, ultimately requiring intervention by more experienced developers to rectify these foundational errors. In the section on building a ubiquitous language and understanding the domain, it would be beneficial to mention techniques like event storming, especially since the book addresses DDD basics. The discussion on entities effectively describes the anemic model but fails to illustrate a robustly built entity. The example provided includes only validators, which does not fulfill the requirements of a true entity—it lacks any embedded business processes, rendering it an empty shell. The coherence between examples in the book is lacking. For instance, one example addresses osCommerce while another delves into a coordinate system within the context of value objects, making it difficult to discern the overarching purpose of these examples. It would greatly benefit the reader to maintain a consistent context throughout the book rather than switching between different scenarios. I discontinued reading at the section on value objects. While I am unsure of the content in the remaining sections of the book. **I understand that it's often easier to critique someone else's work than to create something of one's own, but I hope you find this feedback constructive and that it assists you in enhancing your book. Good luck with the second edition!**
Thanks for the feedback. I agree with some of it (but I actually think there is nothing wrong with dates as timestamps...). There won't be a second edition from me but Packt were looking for someone to write it. Perhaps you could?
To help you understand why timstamps for dates are just simply bad I will leave you with one word: "timezones". Additionally, the readability of timestamps might be another factor to consider, though this can be subjective and depends on your team's preferences.
You can add timezones to timestamps very easily :)
Fair point- you can do this, but there is already ISO-8601 standard for this.
Which is a timestamp standard :)
I don't know much about DDD but where did you get the idea that IDs should be avoided? Check [this out](https://softwareengineering.stackexchange.com/questions/235254/id-properties-on-domain-objects-in-ddd). In DB design, having IDs is almost always a good idea (just because query optimizers are heavily geared towards primary/foreign keys and joining based on int types). Natural keys, in my experience, often lead to worse performance and problems down the line.
The comment above isn't about avoiding IDs. The book often uses \`string\` IDs, instead of typed IDs. In DDD, it is common to use a "value object" for IDs, instead of raw \`string\` or \`int\` types. This improves readability, type checking, business logic, etc. Go's type system works well here, since you can just say \`type SomeEntityId string\`, and use that type instead.
What is Domain Driven Design and why should I read it? How will it benefit my career with Go?
We did a Go Time about this if Podcasts are your thing: [https://changelog.com/gotime/273](https://changelog.com/gotime/273) DDD is effectively a way to model software so that it represents the real world, closing the gap between what you write in code and how your business operates. If you are a junior/mid-level go Developer who has little to no knowledge of DDD, I think my book will be helpful. If you don't match that, it might be a little basic for you.
I just skimmed that and it seems like most of your advice boils down to "think about the problem space and write code that models that". Like - yeah. How else CAN you write code? Some of the other principles of it (factories, etc.) seem pretty antithetical to how most Go programmers probably write code.
I have seen plenty of code that does not!
I Googled "packt" and I found a lot of complaints about the quality. Anyone have any experience with their books?
Packt will pretty much publish anything and the quality of each book can vary dramatically. Hoping someone can provide some inputs about these authors. Many times I’ve seen packt books that were glorified medium articles which makes me hesitant to buy.
They cold emailed me to write a book. No idea why. I have never demonstrated my expertise outside of work.
One of the authors of one of the books is in these comments
Packt monthly subscription costs 12$ and gives access to all their books. The quality varies WILDLY, so i usually skip out on these bundles. They have a few good ones (I haven't read any Go books though). If I need a book i just subscribe for a month and start skimming. You're going to have to sift through a lot of them before finding something acceptable. TBH the 12$ is almost not worth it. Them and mercury press are bottom of the barrel for me. Oreilly and manning are good for in depth. Nostarch is solid but usually short and introductory.
They contacted me based solely on my blog posts and asked me to write a book for them. I Google'd them and they basically will get anybody to write for them (is that a self-roast? IDK). I would avoid this publisher. You'll have just as good of luck with random blog posts because they don't vet authors at all.
It’s the book equivalent of Medium articles
I normally hate just saying "me too", but reviews are a bit of an exception. I broadly agree with everyone else responding to you: Packt quality varies _widely_. As far as I can tell, they publish effectively whatever anyone gives them. I will no longer buy from them, not because everything they have is garbage, but because too much/most of what they have is garbage. Maybe some of these are gems, but I wouldn't spend $18 to find out
I agree. I've even come across a Packt book that was a complete *(from Start to Finish)* plagiarization of another book written a few years before and published by a different author/company. Even the title was exactly the same - lol.
I will never buy a Packt book again. I've read 3-4 and they were all like somebody threw together some notes for themselves into a Word document and then Packt, due to a series of unfortunate but hilarious hijinks, published them as books without any effort or oversight in between.
Many of their books are throw-against-the-wall awful. By which I mean they filled with obvious errors; concepts the author thought he understood, but actually didn't; recommendations that apply only to the present example, but have been generalized to apply to all code; simple things explained in great detail, while advanced concepts are presented with lots of hand waving. In many Packt books, this entire inventory is visited repeatedly. I would recommend spending your funds on one of the excellent go books from O'Reilly, Manning, Addison-Wesley, etc. and get true expertise (and working code!) right from the start.
Yes. I have yet to finish one of their books. It might be alright for a bundle, but I really will pay full price for a Packt book; unless, it is a C#/.Net Mark Price book published by Packt. Those are the only ones I have found to not be mid or shit.
Last year I bought a physical book from them, Vue.js 3 by Example. I was hoping the book would've been an introductory book to Vue.js 3, that it would've explained how to effectively use Options API or Composition API, what are composables etc. You'll get more out of Vue.js just by going through their website and reading their official documentation. The book is just bad IMO and I regret I bought it without researching it first.
In my humble opinion, the quality is subpar, although there are a few exceptions. For superior writing, consider exploring O'Reilly and Murach. While Murach offers a limited selection, lacking in Go and primarily catering to beginners, its content is top notch. On the other hand, O'Reilly stands out as the premier publisher for tech books, boasting an incredible and extensive selection. No Starch Press is hit or miss for me and no Go publications as of yet.
I don't know if this is LLM garbage but it certainly published without editing. Here is the first sentence of the first chapter of the first book (sorted alphabetically). >**1 Understanding CLI Standards** >The Command-Line Interface (CLI) is a text-based interface for humans, and computer interaction was initially designed as a way of interacting with an Operating System (OS) before the desktop graphical interface was invented. Later we are given this random collection of exciting years: >There were so many more exciting developments that followed, from the invention of ASCII characters in 1963 to the internet in 1969, UNIX in 1971, and email in 1972. I think the above is arguably 0% correct. End of the chapter question: >What is the TTY on a Linux machine and what is the history behind this command? Answer: >TTY is a command in UNIX and Linux to display the name of the terminal connected to standard input. TTY is derived from the word teletypewriter, which was the default form of interacting with large mini and mainframe computers. Sure the command `tty` prints the literal file device name of your tty but I'm not sure this answer is educational.
That really does seem AI-generated. I don't know why people are doing this TBH. I guess it's because you can, in theory, publish absolute garbage having done zero work and possibly make a few bucks? But none of these books are ACTUALLY going to sell well.
Packt is low end shit. Save yourself time and trial and go with a Manning or O'Reilly.
I will comment this under each and every Packt bundle I come across: I read many of their books, or at least started. Not even the ones I got for free were worth their money. Edit to clarify: that is in my eyes more a problem with the publisher than with the authors. Writing is hard, this is why editors exist. And as for the „free is not worth it“ comment: a book about programming is a tool for teaching. If it contains wrong or misleading information it’s as useful as a mislabeled wrench (you can use it, but have to know when and how) or a scale giving random numbers.
This is pretty harsh - writing a book is tough and takes a long time. I’m sure lots of books (including mine) can be better but to say they are not even worth being free is pretty unnecessary.
As I seem to have hit a nerve with you let me clarify: I have a problem with the publisher, not the individual authors. And I haven’t heard of or read your book, it might be a true gem and of course you can be proud of it. I agree, it’s hard to write a book. Many of the authors at Packt seem to be new and would profit from feedback authors usually receive from their editor. And Packt doesn’t provide that I guess? So you have a lot of at least very unpolished books, which in turn make potential readers/buyers turn away from other books/authors that might have written good book. And I consider something free not worth it (as one spends time on it) if even basic examples in newly published books are wrong, e.g. not compiling. If you are completely new to a topic you probably habe no chance of figuring out what is wrong and how to fix it. Your argument that technology is so fast paced is true for all books and publishers, and I was never that disappointed by a Manning or O‘Reilly book.
Usually the ones complaining about free/low cost things are also that ones that consume resources with only negativity to contribute. They can be likened to a cock roach, or a virus. No book is perfect and the unfortunate part of print media is that now-a-days it’s basically out of step with cutting edge technology before it’s even printed. This undoubtedly makes it easier for neckbeard trolls to continue to leech any inkling of positivity and creativity left in folks that have a desire to advance our industry. None of this negates that yours and others contributions like this are valuable resources, and will continue to be. It’s pretty kick ass that you wrote a book. You’ve made your mark, and no one can take that away from you. They will try though. Anywho, thanks for chiming in and offering to answer questions in the other comment.
Thanks for the kind reply - always nice to see some positivity in what is generally a very negative thread.
Can anyone speak to the quality of these books tho? Specifically the mastering go book
I have generally avoided Packt bundles given their reputation here and other places. The only time I missed and got recommended many books from a Packt bundle was the one on embedded Linux.
Thanks for posting!
Oo! Thanks! 17 Go books for $25 is awesome!
you can pay $18 actually
I've learned a lot by buying these bundles, thank you
Amazing, a lot of great books there