Transcripts for 2024-04-16-enterprise-angular

en-US/2024-04-16-enterprise-angular/0-introduction.txt

@@ -0,0 +1,48 @@
+[00:00:00]
+>> So my name is Lucas Ruebbelke. I've been a principal engineer for many years and done a lot of work for anywhere from startups to Fortune 100 companies. And the goal of Enterprise Angular is that when you start to program in a context where there's scale, things change.
+
+[00:00:29]
+What I'm hoping to target is developers that not only wanna learn how to write high-quality code in Angular. But also to start to be exposed and understand the principles that really factor into just building large-scale applications and what that looks like and the architecture. Now, doing enterprise development without an enterprise is a little bit tricky as well as it can be very overwhelming.
+
+[00:01:07]
+And so this is where you'll notice on the companion site and the repository, it's enterprisey. And so what I'm hoping to do is, for those who are curious to learn how to build enterprise products and applications that were writing code, but we're just being a little bit more enterprisey about it.
+
+[00:01:32]
+We're going to start at a high level of abstraction and work down. And with that said, the first thing that we're going to start with, and this is incredibly important, is we're going to talk about the domain and domain-driven design. From there, we're going to talk about monorepos in tooling, and then micro-frontends.
+
+[00:01:59]
+And moving on to reactive architecture, state management, standalone components, and then we are going to get into unit testing, end-to-end testing, performance and tuning, and deploying. One of the things that I've learned in my years as a programmer is, there's this arc that you follow in your career that when you start as a new programmer, the tension and the challenge is trying to figure out how things work.
+
+[00:02:41]
+And ultimately, your focus shifts on to how do things work together. And so this is where somebody who is like a principal engineer or an architect that they spend a lot of time thinking about, not how things work, but how they work together. And I would go as far as to say that if you were to continue up the corporate ladder to becoming executive leadership, and at the highest ranks of an organization, well suddenly your job starts to shift into how do people work together?
+
+[00:03:24]
+And how do you get people to work together, to make the things work together, to make the things work. As you do this, the abstraction layers just keep getting higher and higher and higher and more conceptual. When you are starting in you're building a little app, your entire focus is just right there on the app itself.
+
+[00:03:49]
+But then I remember when AngularJS came out, the top question on Stack Overflow for years was, how do two controllers talk to each other. Is that there was clearly a need to divide these controllers, but then what? How do they communicate together? And so not only are we focusing on how things work together and fit together, but how do we divide them in a way that makes sense, that we're not creating coupling, but we're encouraging cohesion, but we're doing it in a way that promotes collaboration and communication.
+
+[00:04:32]
+And so as we get into domain-driven design, this is a topic that, I think I've always been passionate about it, but I didn't quite have the semantics in place to really understand kind of the importance of it. But, when you talk about domain driven design, ultimately it's about how do you conceptually divide and organize your business domain in a way that you can then write your code to pattern the domain.
+
+[00:05:16]
+And I've seen a lot of really bad things happen or costly things or cumbersome things, just a lot of problems when you have a code base that is not reflective of the business domain that it's actually operating in. Because you might have a portion of the business domain that needs to change, but because the code doesn't represent that, to go and make that code change is exponentially expensive.
+
+[00:05:49]
+And one of the companies that I've worked for, they're spending a ton of money breaking up their monolith into microservices. And why are they doing that? Because it's simply too hard to make a change in one piece. It's like Jenga, the game where you've got the little blocks, and if you just do one wrong, the whole thing tips over.
+
+[00:06:20]
+Everything is bundled together and it's very hard to make changes. It's very hard to move and to innovate. And it's because coupling is bad, as a result, it makes communication cumbersome. And I believe that when you get your business stakeholders, the people that understand the business domain, and the engineers in a room, and they are clear that they have a conceptual understanding and an agreement on what the domain is, and what it's supposed to do.
+
+[00:06:59]
+That sets the stage for establishing what we call a ubiquitous language where everybody's using words that mean the same thing. That we understand when we say case, or flight, or these different words within the business domain, specifically what it means and in the context that it means. And these conversations, I think for cowboys who wants to just run in code is, I understand that on the surface, maybe it's not super exciting.
+
+[00:07:41]
+There's nothing quite as exciting as, my gosh, it's a green field and I'm gonna run into the green field and I'm just gonna write code, but oftentimes the best code that we write is the code that we don't write at all. And the greatest thing that we can have is, as engineers, is a clear understanding of the business domain that we're operating in, where the lines of division are.
+
+[00:08:13]
+And I would say, if you want to level up and really kinda go to the next level, understand how they fit together to serve the business and to drive value. Is that when you have an engineer that can actually talk about business outcomes, that is incredibly valuable and non-technical people respond very well to that.
+
+[00:08:37]
+So this is where we're starting very high. And we're going to talk about domains for just a moment. And my goal is to write as much code as possible. But before we do that, we have to have a clear understanding of what we're working in.
+