5 ms·
So is this a good book? Are there any other software architecture books that are recommended reading?
by Sakos 2y ago
So is this a good book? Are there any other software architecture books that are recommended reading?
- hemantv 2y agoGame Programming Patterns was one which had a big impact on me. Other was Effective Engineer
- vendiddy 2y agoIs Game Programming Patterns relevant to those who are not building games?
- mon_ 2y agoRelevant excerpt from the Introduction chapter: --- Conversely, I think this book is applicable to non-game software too. I could just as well have called this book More Design Patterns, but I think games make for more engaging examples. Do you really want to read yet another book about employee records and bank accounts? That being said, while the patterns introduced here are useful in other software, I think they’re particularly well-suited to engineering challenges commonly encountered in games: - Time and sequencing are often a core part of a game’s architecture. Things must happen in the right order and at the right time. - Development cycles are highly compressed, and a number of programmers need to be able to rapidly build and iterate on a rich set of different behavior without stepping on each other’s toes or leaving footprints all over the codebase. - After all of this behavior is defined, it starts interacting. Monsters bite the hero, potions are mixed together, and bombs blast enemies and friends alike. Those interactions must happen without the codebase turning into an intertwined hairball. - And, finally, performance is critical in games. Game developers are in a constant race to see who can squeeze the most out of their platform. Tricks for shaving off cycles can mean the difference between an A-rated game and millions of sales or dropped frames and angry reviewers.
- richrichie 2y agoPerformance part alone is worth reading about game development for non game developers. Retail off the shelf machines these days are so powerful that it encourages sloppy design and development.
- water-your-self 2y agoPerformance is very much still relevant in the modern day, even given the area under the curve of moores law
- zamalek 2y agoGames are just normal software dev dialed up to ten, though there are many problems that game developers enjoy not having to care about (and visa-versa). Attempting to make a basic 3D engine is probably a good exercise for all developers - even if it goes uncompleted.
- smnplk 2y agoIs GPP relevant if you don't want to do OOP ?
- yashap 2y agoHaven’t read this one, but have read a few - “Domain Driven Design” (by Eric Evans) was the most influential for me.
- jojohohanon 2y agoI am very interested in learning more / honing my design skills, But Like everyone else my time is extremely limited. Could you say a few words about DDD stood out for you and what other books you might compare it to?
- sbayeta 2y ago(Not gp) I read this book more than a decade ago, when I was very inexperienced. The thing I remember the most, and I think the most valuable to me, is the idea of defining a shared domain language with the business domain experts, with a clearly defined meaning for each concept identified. For instance, what a "frozen" account exactly means, what's the difference with a "blocked" account. These are arbitrary, but must be shared among all the participants. This enables very precise and clear communication.
- darkerside 2y agoI think that's the core idea. The layer on top the idea that that domain language should be expressed in an isolated core layer of your code. Here lies all your business logic. On top of that, you build application layers to adapt it as necessary to interact with the outside world, through things like web pages, emails, etc. as well as infrastructure layers to talk to your database, etc.
- zeroCalories 2y agoAt my job we have a shared glossary and data model that we use with business people, but do you really need a whole book on that?
- jameshart 2y agoDDD is about a lot more than just defining what it calls ‘ubiquitous language’. It helps you figure out how to constrain which concerns of the language used in one domain need to affect how other domains think about those things - through a model it calls ‘bounded contexts’. Like, in your fraud prevention context, ‘frozen accounts’ might have all sorts of nuances - there might be a legal freeze or a collections freeze on the account, with different consequences; outside the domain, though, the common concept of ‘frozen’ is all that’s needed. DDD gives you some tools for thinking about how to break your overall business down into bounded contexts that usefully encapsulate complexity, and define the relationships between those domains so you can manage the way abstractions leak between them. No silver bullet, of course, but, like most architectural frameworks, some useful names for concepts that give you the metavocabulary for talking about how to talk about your software systems. This brief chapter from the O’Reilly Learning DDD book gives a good flavor of some of the value of the concepts it introduces: https://www.oreilly.com/library/view/learning-domain-driven-design/9781098100124/ch04.html https://www.oreilly.com/library/view/learning-domain-driven-...
- mbb70 2y agoDesigning Data-Intensive Applications by Martin Kleppmann. It's my "this is the book I wish I read when I started programming"
- adamors 2y agoWhen you started? I mean it’s a good book but it would be wasted on beginners.
- mbb70 2y agoMaybe not when I started, but after years of hard lessons working with HDFS, Cassandra and Spark (not to mention S3, Dynamo and SQS) seeing all those hard lessons pinned down like butterflies in a display case made me jealous of anyone who found this book early
- pragmatic 2y agoWe’re about due for a new edition with some updates. I read it again just recently and in certain sections I would love some updates. Many things have changed in 7 years.
- JackMorgan 2y agoAn absolutely excellent book! I learned so much going through it slowly with a reading group I started at my job.
- notduncansmith 2y agoI read this book in the first few years of programming professionally, and in my naïveté I was so eager to apply the patterns therein I missed out on many opportunities to write simple, straightforward code. In some ways it really hindered my career. I don’t blame this on the book, of course; ultimately the intuition it helped me build has been very helpful in my work. With that said, as a particular type of feisty and eager young programmer at the time, I can now say I would have benefitted at least as much from a book titled “Designing Data-Unintensive Applications” :)
- mehagar 2y agoClean Architecture and Fundamentals of Software Architecture: An Engineering Approach.
- GiorgioG 2y agoUgh enough with clean architecture. So much boilerplate. Uncle Bob please retire.
- srid 2y agoJuval's "Righting Software" comes to mind. In particular, this article "Volatility-Based Decomposition" is a good introduction: https://www.informit.com/articles/article.aspx?p=2995357&seqNum=2 https://www.informit.com/articles/article.aspx?p=2995357&seq... (Note the electricity analogy)
- ChrisMarshallNY 2y agoWriting Solid Code, from 30 years ago, by Steve Maguire, was a watershed, for me. Many of the techniques, therein, are now standard practice. It also espoused a basic philosophy of Quality, which doesn’t seem to have aged as well.
- throwaway81523 2y agoAOSA, https://aosabook.org/en/index.html https://aosabook.org/en/index.html is good. Also, study the code of lots of different systems.
- JackMorgan 2y agoI learned a lot about good software design from Structure and Interpretation of Computer Programs. It's free and has 350+ exercises. I just committed to doing one a day for a year. I learned so much from that book it's like I aged ten years in that one year. Revolutionary for me. I also loved - Designing Data-Intensive Applications - Design Of Everyday Things I've got a list of other influential books with my thoughts here: https://deliberate-software.com/page/books/ https://deliberate-software.com/page/books/ My controversial takes are that the whole series of Domain Driven Design books are pretty poor. I've seen several teams fall into a mud pit of endless meetings arguing about entities vs repositories. Same thing with Righting Software. The books are all filled with vague statements so everyone just spends all this time debating what they mean. It turns teams from thinking critically into religious bickering. Same for all the design patterns books.