Software architecture pattern
-
How do you desired which of the architectural pattern to work with?
-
How do you desired which of the architectural pattern to work with?
I reject the premise of the question.
-
How do you desired which of the architectural pattern to work with?
Experience and knowledge and what you have learnt about the business requirements.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
How do you desired which of the architectural pattern to work with?
A pattern is where you're repeating the same block of code; it is now a pattern; your pattern. The fact that no one has used it before, or named it, makes no difference.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
How do you desired which of the architectural pattern to work with?
Many patterns, such as those in the GoF book, aren't "architectural". They're more tactical, although they can help to make an architecture better. Jim Coplien, who was well-known in the C++ world, got involved with patterns early on. Later, he said that there was too much focus on patterns. The emphasis needs to be on encapsulation, polymorphism, and inheritance. Patterns are the exception when those things, by themselves, don't produce loosely coupled code. To understand a pattern, you need to have seen what code looked like before the pattern was applied, and after. Then, when you write or find code that looks like the "before" code, you'll know how the pattern can improve it. That's usually how a pattern gets used. How code evolves to satisfy its specifications is what determines which patterns are used; it is wrong to start out by saying which patterns will be used before you have a good sense of the high-level design.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
I reject the premise of the question.
Why rejecting what you should be able to deal with?
-
A pattern is where you're repeating the same block of code; it is now a pattern; your pattern. The fact that no one has used it before, or named it, makes no difference.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
Thank you
-
Many patterns, such as those in the GoF book, aren't "architectural". They're more tactical, although they can help to make an architecture better. Jim Coplien, who was well-known in the C++ world, got involved with patterns early on. Later, he said that there was too much focus on patterns. The emphasis needs to be on encapsulation, polymorphism, and inheritance. Patterns are the exception when those things, by themselves, don't produce loosely coupled code. To understand a pattern, you need to have seen what code looked like before the pattern was applied, and after. Then, when you write or find code that looks like the "before" code, you'll know how the pattern can improve it. That's usually how a pattern gets used. How code evolves to satisfy its specifications is what determines which patterns are used; it is wrong to start out by saying which patterns will be used before you have a good sense of the high-level design.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Experience and knowledge and what you have learnt about the business requirements.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
What if this is your startup and idea, and you've yet to write the business requirement? Your experience level is coming from a lot of books and youtube videos you have read and watch.
-
What if this is your startup and idea, and you've yet to write the business requirement? Your experience level is coming from a lot of books and youtube videos you have read and watch.
Tabah Baridule wrote:
you've yet to write the business requirement
Then why are you thinking about architecture patterns. Get you business plan and requirements sorted and THEN start looking into what platform(s) you will service and the different patterns that will meet your requirements.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
:thumbsup::thumbsup: Thank you, permit me to share this as a tweet.
OK.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
How do you desired which of the architectural pattern to work with?
The most correct thing previous commenters posted is that you need to handle business requirements first. The other correct thing is that GoF patterns are mostly tactical. Given that in my answer I'll assume is that architectural patterns are monolith, microservices, CQRS etc. With that said I'd start from monolith application since microservices bring a lot of overhead that you might not need until you've pitched a PoC to some investors or might not need it at all if you're not going to have a team of sufficient size or your application won't endure high loads. Then your application will evolve according to your business requirements and also to a fact that your understanding of business will evolve too. Say you'll discover that your business problem contains of multiple subdomains. Then you can handle them via vertical slices. Or you may need to handle spikes in application load. Then you might need to extract some microservices. In general, my advice is to start with the simplest solution unless you're encounter requirements to act otherwise.
