I bought your book. Great stuff. The most important single line that I was looking the answer for was "bread vs depth" of knowledge as the balance between an architect vs a developer. And as an aspiring architect who's not a developer. That told me how much of development do I need (breadth) to be an effective architect. Thanks!
In my point of view, Architecture is an abstract and platform independent blueprint of system, on other hand design is platform dependent version of architecture. For example, Client-Server is an architecture which can be designed in multiple way based on requirement and platforms (AWS, GCP, On-premises Linux server etc.). So, Architecture and design(High level) are complementary to each other but not substituting each other. We can only check design is complementing architecture or not. Further Design can be segregated in two types based on scope: High Level Design and Low-level Design. Implementing Strategy Design Pattern is part of low-level design, it has nothing to do with architecture, The rationale of using Strategy Design Pattern is How to achieve reference architecture based on best practices (It can be archived without using Strategy Design Pattern).
Thanks Richard for this great explanation, l can borrow more from this criteria to evaluate decisions that require approval by the Architecture Review Board or just an approval within the teams hence saving time on the decision making process. And also customise the criteria to fit a value stream.
Thanks for the video! I have a question though: if the practice of Domain-Drive Design is used, would you say that is more part of Architecture (as you've described it), or as part of Design? Some people (not you) might find this question silly because DDD has "Design" in it, therefore the categorization should be obvious. However you've mentioned the notion of Bounded Context with regards to Microservices, so if Bounded Contexts are determined using DDD, would that not mean that Design (in the sense of DDD, not of the lower-level Design Patterns) actually influences Architecture? DDD is also split into "Strategic" and "Tactical", which further deepens the question.
I think there's an element of BOTH in DDD. We can leverage DDD in architecture to identify domains, subdomains, and components, which helps us design a better logical architecture.
Hmm the trend nowadays is people using the term “system design” during interviews (such as design Instagram or design Twitter), but it involves making architectural choices. Good video 👌
Here's a good way to think about it: "Design for me a 10 story office building". Would you like an architect to do that or a construction worker? We tend to use the words "design" and "architect" interchangeably, but maybe we shouldn't....
@@markrichards5014 we tend to use this beaten horse analogy to talk about software design, but maybe we shouldn't. Building architecture is not in the same league as software architecture for lots of reasons (some other time 🙂). For me ultimately its all design, only the levels and impact differ. It also depends on what kind of architect you're talking about: software, enterprise, solutions, infra, data, ad infinitum. To use your analogy, if a construction agency (aka developers) is sufficiently experienced and well known they might also generate design ideas that a good architect will incorporate into the overall deliverable. Vice versa, sometimes architects have a good handle on construction techniques and materials knowledge (aka design patterns and code optimisation techniques) and they can influence the lower level design of the overall deliverable. By equating a developer to a "construction worker" you are saying a developer has no business thinking/working architecturally, so best leave it to "The Architect". This does nothing more than continue to enlarge the divide between the two roles and after a while it becomes a self-fulfilling prophecy i.e. "developers don't think architecturally", how would they if we keep ostracizing them like that? This is why these kinds of analogies must stop and we should see software design as its own thing.
Many thanks for this video Mark! May I suggest a subject for upcoming videos? When to use pub-sub / event streams vs. queues in EDA? what are the effects on resilience and integrity of the system and what are the solutions to the downsides of each?
@@markrichards5014 Hi, I think I need to elaborate a bit about the issue I'm talking about. I'm asking about this because I watched ALL your videos (many thanks!) but I never saw any reference to the following issue: Let us assume that service A needs to send a message to multiple micro-services, B being one of them. It is critical that service B will get the message for a certain process to complete. In many of the videos I hear you talking about broadcasting such messages. I'm assuming that there are generally three ways to send messages but I can't see how any one of them fits the purpose: 1. using queues: forces service A to "know" about service B, which ruins the whole point of broadcasting. 2. using pub-sub/fan-out: if service B is temporarily down, it will never get the message. 3. using streams: service B must somehow preserve the "last point" in the stream that it has processed in case it goes down. then it must return to that point when it's up again. this gets event more challenging if service B has multiple running instances. So .. what am I missing ? Or is it something that's missing in the videos ? Many thanks, Nir.
@@nir8924 With asynchronous pub/sub processing you can guarantee that Service B will at least receive the event (even if it is temporarily down) by making it a durable subscriber. This is the same with P2P as well (making the message persisted on the queue). So I'm wondering, in your scenario, is it the situation where Service A needs to know that Service B has received the event? Also, check out Lesson 81 on the Workflow Event Pattern for error processing in this scenario for Service B.
@@markrichards5014 wow I didn't expect a "private consulting" here, I thought I'll just help the channel :) I don't have a case in hand now, it's a theoretical question. I'm talking about a situation when we don't want A to know about B (for decoupling purposes). The problem with pub/sub (event a durable one) is that it forces B to keep record of each handled message in order to prevent duplicate processing (imagine a payment that will take place multiple times). I'll go watch lesson 81 again, to see if I'm missing something, and maybe I just don't know enough pub-sub systems to know that a single-delivery is a thing. I do *think* though, that it's not an obvious thing that can simply be ignored. HUGE thanks for this correspondence! Nir.
Perhaps a good architect may want to enable more design and less architecture. One feels this enhances agility, a quality attribute you talk about a lot.
On this, I had a thought: the published JSON schema for a domain event relied upon by clients feels architectural. If I wanted to rename a key, say, it is high effort for client and server. Then I use Kent Beck's Parallel Change, meaning a reduced effort, moving closer, even slightly, towards design. I can expand (c.f. your Building Evolutionary Architectures book) to support two names and then contract once clients migrate.
