[HN Gopher] Just Enough Software Architecture
___________________________________________________________________
Just Enough Software Architecture
Author : teleforce
Score : 94 points
Date : 2024-06-15 19:02 UTC (3 hours ago)
(HTM) web link (www.georgefairbanks.com)
(TXT) w3m dump (www.georgefairbanks.com)
| Sakos wrote:
| So is this a good book? Are there any other software architecture
| books that are recommended reading?
| hemantv wrote:
| Game Programming Patterns was one which had a big impact on me.
|
| Other was Effective Engineer
| vendiddy wrote:
| Is Game Programming Patterns relevant to those who are not
| building games?
| mon_ wrote:
| Relevant 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 wrote:
| Performance 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.
| yashap wrote:
| Haven't read this one, but have read a few - "Domain Driven
| Design" (by Eric Evans) was the most influential for me.
| jojohohanon wrote:
| I 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 wrote:
| (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 wrote:
| I 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 wrote:
| At 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?
| crdrost wrote:
| Not the person you're asking but thought I would chip in.
|
| _Domain Driven Design_ has a lot of good ideas, but then I
| consistently see them misrepresented by others who seem to
| half-understand it?
|
| Probably the clearest example is the idea of a "bounded
| context." You will find microservice folks for example who
| say you should decompose such that each microservice is one
| bounded context and _vice versa_ , but then when they
| actually decompose a system there's like one microservice
| per _entity kind_ (in SQL, this is a _relation_ or _table_
| , so in a microservice pet-adoption app there would be a
| cat service, a dog service, a shelter service, an approval
| service, a user service...).
|
| The thing is, Eric Evans is pretty clear about what he
| means by bounded context, and in my words it is taking Tim
| Peters's dictum "Namespaces are one honking great idea--
| let's do more of those!" and applying it to business
| vocabulary. So the idea is that Assembly Designer Jerry on
| the 3rd floor means X when he says "a project," but our
| pipefitter Alice on the shop floor means something
| different when she says "a project," and whenever she hears
| Jerry talking about a project she is mentally translating
| that to the word "contract" which has an analogous meaning
| in her vocabulary. And _DDD_ is saying we should carefully
| create a namespace boundary so that we can talk about
| "pipefitting projects" and "pipefitting contracts" and
| "assembly-design projects" and then have maybe a one-to-one
| relationship between pipefitting contracts and assembly-
| design projects. Eric Evans wants this so that when a
| pipefitter comes to us and tells us that there 's a problem
| with "the project," we immediately look at the pipefitter
| project and not the assembly-design project. He really
| hates that wasted effort that comes from the program not
| being implemented in vocabulary that closely matches the
| language of the business.
|
| So if the microservices folks actually had internalized
| Eric's point, then they would carve their microservices not
| around kinds of entities, but rather _archetypes of users_.
| So for the pet adoption center you would actually start
| with a _shelter admin service_ and a _prospective adopter
| service_ and a _background checker_ service, assuming those
| are the three categories of people who need to interact
| with the pet adoption process. Or like for a college bursar
| 's office you would decompose into a teacher service,
| student service, admin service, accountant service,
| financial aid worker service, person who reminds you that
| you haven't paid your bills yet service.
|
| So I thought it was a really good read, that's actually a
| really interesting perspective, right? But I don't think
| the ideas inside are communicated with enough clarity that
| I can bond with others who have read this book. It is kind
| of strange in that regard.
| globular-toast wrote:
| One of my favourite books. Some people seem to prefer
| "Implementing Domain-Driven Design" by Vaughn Vernon. I have
| both on my shelf but I've never been able to read much of the
| latter.
|
| Clean Architecture by Robert C. Martin has a lot of the same
| stuff distilled into more general rules that would apply to
| all software, not just "business" software. It's a good book
| but overall I prefer DDD.
| mbb70 wrote:
| Designing Data-Intensive Applications by Martin Kleppmann. It's
| my "this is the book I wish I read when I started programming"
| adamors wrote:
| When you started? I mean it's a good book but it would be
| wasted on beginners.
| mehagar wrote:
| Clean Architecture and Fundamentals of Software Architecture:
| An Engineering Approach.
| GiorgioG wrote:
| Ugh enough with clean architecture. So much boilerplate.
| Uncle Bob please retire.
| srid wrote:
| Juval'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&seq...
|
| (Note the electricity analogy)
| matt_lo wrote:
| Great book. I think it's more ideal for folks who solution design
| day-to-day. Better when you have experiences to relate back with.
| pbnjay wrote:
| Published in 2010? Curious how much of it has survived since
| then?
|
| I like "Design It" because of some of the workshop/activities
| that are nice for technical folks who need to interact with
| stakeholders/clients (I'm in a consulting role so this is more
| relevant). Also it doesn't lean hard on specific technical
| architectural styles which change so frequently...
| zeroCalories wrote:
| Process at my work is heavily influenced by this book, and I
| think it gives a pretty good overview of architecture and
| development processes. Author spends a lot of time in prose
| talking about mindset, and it's light on concrete skills, but
| it does provide references for further reading.
___________________________________________________________________
(page generated 2024-06-15 23:00 UTC)