#Software Architecture
1 messages · Page 1 of 1 (latest)
<@&987246841693360200> please have a look, thanks.
While you are waiting for getting help, here are some tips to improve your experience:
If nobody is calling back, that usually means that your question was not well asked and hence nobody feels confident enough answering. Try to use your time to elaborate, provide details, context, more code, examples and maybe some screenshots. With enough info, someone knows the answer for sure.
Don't forget to close your thread using the command </help-thread close:1027500463647621170> when your question has been answered, thanks.
well, in simple terms, its about how u design ur project and code.
how readable and understandable it is. deciding when to create new classes and methods and when not.
how well ur code supports future modification and changes without having to make big changes. correct use and knowledge of certain patterns. all of that and more
its the main skill that differentiates a beginner from a senior
they all get the job done, but the junior would just go for some hacky quick solution and not think too much about it, as long as it works
the senior will code for readability and think ahead, already suspecting certain changes in the future and design the code with that in mind
the only way to learn and improve that skill is by pure practice
u have to write and design a certain amount of projects to learn how to do it best
there are ofc also books that help with it, like Clean Code, or reading and understanding certain patterns
these terms are often misused, sadly
often our industry doesn't take these (or any..) terms seriously, and uses them arbitrarily
so will try to provide some coherent definition, and examples to help you understand what we mean by architecture more concretely
architecture in software is the highest, most abstract way we reason about software
foundational structure and organization of the project
so it's not about the code at all, or singular classes, it's more about modules, and how they interact with each other
not to be confused with the design, and design patterns, that are mid-level abstractions
and not to be confused with even more narrow scope, classes, methods, clean code, refactorings, readability, naming.. which would be implementation/solution patterns (the lowest way of abstraction, code level)
so, to give some examples of this
oh yeah, patterns are common solutions to specific problems
the idea is that each complex piece of software is built of many tiny common problems, that we all face daily, and they can be extracted and reused as more general solutions to that class of problems
architectural patterns you might have already used: MVC, microservices, event-driven, hexagonal architecture, spring database - persistence - business - presentation layers
so all those are very high level, they say nothing about the code, or classes
it's just structure and organization
while design patterns you might have already used: builder, factories, observer, strategy..
which are more concrete and lower level solutions, usually multiple classes and interactions between them
but still not quite implementation level, where you worry about readability, naming, specific language features/syntax etc
design patterns are language agnostic (even within a single language, you can implement them in completely different ways)
the idea behind the term is architecture blueprints, very foundational structural but yet abstract plans
before any concrete pouring happens ^^
and yeah, tons of books about this
you have uncle bob's (robert c. martin) clean architecture, a craftman's guide to software structure and design
since i have these, let's see how they defined the term :p
What Software Architecture Is and What It Isn’t
There are many definitions of software architecture, easily discoverable with a web search, but the one we
like is this one:The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.This definition stands in contrast to other definitions that talk about the system’s “early” or “major” design
decisions. While it is true that many architectural decisions are made early, not all are—especially in Agile or
spiral-development projects. It’s also true that very many decisions are made early that are not architectural.
Also, it’s hard to look at a decision and tell whether or not it’s “major.” Sometimes only time will tell. And since
writing down an architecture is one of the architect’s most important obligations, we need to know now which
decisions an architecture comprises.
Structures, on the other hand, are fairly easy to identify in software, and they form a powerful tool for system
design.
they also use this defintion
The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.
which is basically how i defined it, they just did it a in more eloquent and succinct way :p
you can also check these and references they use: https://en.wikipedia.org/wiki/Software_architecture; https://en.wikipedia.org/wiki/Architectural_pattern (these books are first and fourth reference on the soft. architecture wiki, so the definition is the same)
Alright thank you guys so much! As a wannabe junior - should I focus more about software design (the lower to mid level of a project - methods and classes and their interactions) or should I also dabble in architecture? It seems online like most say to focus more on design for now since architecture appears to more of a senior concern?
yup, usually that wouldn't be your domain at all
just learn the popular architectures and know when and where to use them. same as you would design patterns. common ones like n-tier, mvc, mvmm etc
as a junior, your will very rarely make those decisions
but you should be at least familiar with some popular architectures, so you can use them
for example spring database, persistence, business and presentation layering
basic patterns maybe, and ideas behind them
what design techniques/resources do you use? Getting taught them in school it always felt very high level which wasn’t that helpful. I know about modelling for analysis and design but that doesn’t seem very popular haha.
tutorialpoint
i prefer books, highest quality and depth, and they are methodological
they guide you in some structured way
and practice
like you said, theory is very abstract, and hard to fully grasp
Alight thank you so much for your answers!
you need practical experience so you can see and feel all the benefits or failings of some design/architecture
you probably went trough something like this with proper OOP
all the different classes, methods, interfaces and abstract classes..
why we do things in a specific way.. like private fields etc
and then those abstract ideas like encapsulation, separation of concerns and so on make sense
just reading about them is pointless, when there is nothing to tie them to
you will forget everything in a week
not all books are very theory heavy and dry tho, there are books specifically tailored to juniors
but with all of them, deliberate practice is the key 
np, and good luck with your journey 💖
Oooo do you have a recommendation?
Yes - practice makes perfect but at least you need a plan and some idea of what you are doing haha. I really need to read up on design patterns.
For me it was a process. Obviously going totally against and suggesting a beginner to invest more time in learning architectures first rather than understanding the programming and cs basics sounds totally unfair and incorrect (which @ripe barn said correctly - its a kind of decision making, more senior level)
Transitioning my career through different jobs gave me a much better idea why we are failing most of the times in order to built an anti-fragile product to keep our users happy. So I took the initiative by myself by asking relevant questions, listening, reading to other product architectures, how they are building great stuffs, asking questions, internet and whole lot more
At the end, it's a matter of tradeoffs, no architecture is perfect, it all depends upon your team and decisions taken along they way.
Facts aside, as others suggested, I'd say if you are a totally beginner in the industry, firstly I'd recommend working on your basics as much as you can (how memory works, object-oriented, clean code, etc.) and they start diving into software architectures (monolith, modular, microservices, n-tier/layered, hexagonal, onion, clean architecture, dependency injection, singleton, factory pattern, etc.)
@scenic vector thank you for your feedback!
No worries bud, best of luck! 😄