 Thank you everyone. So today I'll be talking to you about domain driven web applications using Backbone. Before we get into what that means, let's take a look at this picture, because I think this is actually a really good metaphor for software development. So if you look off into the distance here, you'll see this ship that's just been launched and it's sailing away. So coming in at the top of the image here is the first plank that makes up the keel of the next ship that they're building in this dry dock. And so in a lot of the same way, we build an application and we ship it. And before it's out of view, we're starting the next one. So what we need is the same architecture that helps us manage the constant turnover of projects so that the next ship we build doesn't sink. So if you look at the last few years of JavaScript development, we've really come a long way in JavaScript engineering rigor on the client side. We've seen some of that in some of the talks today about test driven development and dependency injection and how we architect our applications. We've implemented all of this stuff, static code analysis, testing, building. So why do so many of our applications still look like piles of coat hangers? They might be well modularized piles of coat hangers, but they're still piles of coat hangers nonetheless. And so what we actually really need is an overall architectural design for our most complex applications. So I'm Bob Holt, as Adam mentioned, I work at Boku. But before joining Boku, I worked at a large consulting firm specialized in clients and financial markets and energy companies. So these are the types of companies that need really big, really complex applications, things like stock trading platforms or how an energy company manages the flow of resources through their system. Traditionally, these are built in .NET or Java, some really historically solid server side language. But over the last couple of years, these applications have started moving to the client side. Traders want to be able to make trades from the golf course on their iPad. We need web applications that can handle that. So what we wanted to do is we use what we call domain driven design on the server side. We want to be able to bring that same architectural style to the client side. Because our applications are no less complex and have no less importance to our clients. They need data integrity and stability. So, but before we go any further, let's be really clear. I'm not saying this is the one way to build applications. This is a strategy, it's particularly suited to large data-centric applications. Other approaches really are equally valid. We're gonna see a very different approach tomorrow with Kujo. Just pick whatever architecture suits your particular application's needs. But please, pick something. But right now, we're talking about domain driven design. So this book came out in 2004, it defined an approach to software development that had been maturing particularly in the Java world for a very long time. So the first part of this book talks about theories and basic implementations of domain driven design. And then the last part of the book actually goes into basically practice exercises of implementing, takes on some more advanced topics, talks about refactoring and actually some software development best practices, how to work with teams, distributed teams, things like that. But today, we're just gonna cover the basics. So what is domain driven design? Let's start by defining domain. So the domain is actually the subject of the program in a lot of software. It's what we call the business of the software. So for example, in an airline booking application, the domain is actual human beings getting on an actual aircraft that exists in the real world. In stock trading, the domain's the universe of actual securities and real life exchanges and people on the trading floor who are actually trading these things. So domain driven design is an architectural pattern that places primary focus on this domain and its real world logic. DDD offers a collection of principles and techniques and best practices and all sorts of things that help us manage these complex applications that are built on this domain. But the question comes up, what if my software isn't complex? So Eric Evans, who wrote domain driven design, isn't even that dogmatic about using it. In his book, he actually suggests putting all the business logic in the UI and shipping it. You know, you don't have the time, the budget, the team capable of pulling this off if you're not building that complex application. So in short, you just make it work. So in DDD, we're really focused on managing complex software. And we take it kind of as a given that when we build complex software, it needs to be based on some sort of domain model. So what's a domain model? It's the image of the business logic and everything that actually exists in the head of an expert in that topic. Generally, that's your client, the business owner of your client. But this has nothing to do with the software at this point. And I'll say it again, it has nothing to do with software. So the domain model is conceptual. So in the same way that an economist is going to model an abstracted version of a real world system with math, we're eventually going to do that with programming. But at this time, when we start conceptualizing this model, it's all theoretical. So let's start building a domain driven application. So we've used this as an example. So this is basically a screenshot from an application we like to use called Bullsverse, it represents a very simple trading application. It's a step up from a to-do type of application, but it's still not a fully fledged operational thing that we would actually ship. So it gives us an opportunity to experiment with frameworks. And we've got it on the client side. We've got middle tier and we've actually got back in. So this is a full end-to-end application that we've built. We can practice with different frameworks and clients and things like that. So we've done this with Backbone and DVD. So anyway, this is the application we're building and you can see your accounts. And you click through to your positions and make trades and things like that. So how do we go about building this? So the first step is to really settle on a framework. We want a framework that's going to support our domain driven ambitions as much as possible, but that also includes staying out of our way when we want to stay out of our way. So it should come as no surprise to anybody in this room that we like Backbone. I like Backbone. So I think Jeremy really summed it up the best in his blog post when he announced the release of 1.0. This is kind of a long quote, but when I'm building complex, customized applications, this cannot be overstated. This is the importance of staying out of my way. You know, when I build a new application, I'm going to do things differently every time. I'm going to set up the file system differently every time. So it's because I've learned something on a past project. Sometimes it's because I just want to experiment, but I don't want to be locked in by my framework into one particular way of doing something. And then building on that, anytime I try to do something with a more prescriptive framework, and then I often find myself running into something when I get to an application this complex that I try to go against what that framework wants me to do, takes me about 10 times as long to get what I need done. Never run into that with Backbone yet, so that's why I particularly love it. So we're going with Backbone, come hell or high water. So let's talk about the process of starting to think through this domain driven design. The most important step of the process is really the discovery phase. So in this phase, we're consulting with the business experts, project managers, business owners, to just build out this model that exists in their heads. We use whiteboards and text documents and things like that. And in doing this, we start to compile what we call the ubiquitous language. So this concept of ubiquitous language is shared among different software paradigms, but most notably with behavior-driven design. So ubiquitous language is a well-defined terminology that all members of the team use in all of their code, all of their documentation, all of their verbal communication, so that everybody who touches the product is speaking the same language from the business analyst to the project manager to the developers. So instead of having to go back and explain to the client, you know, well, our database is relational and this and this, and we're using the flyweight pattern in this way, we're not going to use that terminology, we're going to use the terminology we've discussed with them and settled on. There's no translation involved, everybody understands. So in this application, we don't necessarily have screenshots to start from, but you can see some of these important terms start to come out. You know, accounts and positions and orders and trade and transfer. You know, this is the process of building out this ubiquitous language. When we say something, it's going to mean the same thing no matter what. And so we have a little cartoon example. So the developer is actually talking to the business owner and trying to refine their idea of the ubiquitous language. You know, we continue to iterate on it as we go along. So the developer says, hey, you know, we've got positions and account and shares and security. The business owner says, well, that's not the whole picture. You know, I'm thinking of lots and, you know, we need to calculate gain and see. So the developer says, well, you know, instead of horseshoeing this new information into the model I already have, which is pretty much what I think a lot of us used to do, maybe still do, we're going to actually take time and incorporate all of this new information into both our mental model and our software implementation once we get down the line. So this is an iterative process. The domain model will continue to change throughout the project as we get greater understanding of both how the software implementation is being put together as well as how, you know, as we deal with it longer the actual reality of the situation. The better abstractions and epiphanies and clarifications will cause us to continuously refine this model. So whenever I say iterative the question comes up, does this mean agile? Not necessarily, as long as you are willing to make your model iteratively perfected. But you can definitely see how an agile methodology would not only accommodate but perhaps even encourage this process. If we're continuously throughout the life cycle of the project iteratively changing the data model, how do we do that without breaking everything? Well, we need to isolate this domain model from everything else. So we want to think of our application as having different loosely coupled layers. So at the bottom here we have our infrastructure layer which is a lot of our services, supporting framework, repositories. Then the next layer up is our domain layer. So this is our model, our data model. Above that we have our application layer which is how our application particularly hums along. And then on top of that is our UI and our views and in our instance it's almost entirely made up of backbone views. So to preserve the loose coupling of this architecture we want to keep these levels strictly separated. The levels above are allowed but not necessarily encouraged to have direct reference to the levels below but that doesn't go the other way. So the levels below have to communicate up the stack with events. And so this really makes sense if you sit down and think about it. Why if I'm building an application should it care what UI is built on top of it? Why when I'm formulating this data model does it care what kind of application is built on top of it? Whenever anything changes it's just going to broadcast an event and whatever application is there is going to catch that event and respond accordingly. And we can see the separation in this example of the file system from that Bull's first application where domain is obviously our domain model. What we call framework is our application layer. It's got various utilities and base objects things that we tend to use throughout our application. Pages and widgets are our views, our UI layer and then services we're going to talk about a little bit more later that's basically our infrastructure layer. Now like any software application we make concessions. This doesn't stay 100% pristine but we have this platonic ideal of DDD that we're aiming for and we can sacrifice this purity for maintainability as long as we are completely cognizant of it and know what we're trading off. So we've got kind of a concept for domain. We've got kind of our framework. Now we need to start expressing this model in software. So our biggest battle here is going to be against complexity. So in the real world 100% accurate representation is going to be endlessly complex. There's this whole network of relationships between objects you know we can't replicate that in software we don't necessarily want to because there are performance implications maintainability implications so how do we simplify our representation of this domain model? Well the first thing we need to do is kind of clarify this relationship. You know like I said in the real world everything has a kind of many to many relationship but we want to kind of whittle this down clarify the relationship and as we come to understand this domain model many of these relationships can be simplified or even eliminated altogether to make the implementation of the software actually easier to produce. So once we've clarified a lot of these relationships then we need to kind of start distinguishing between entities, value objects, and services. So entities are objects and value objects are objects but entities have identity. So you know we need to keep track of a particular instance of an object throughout its entire life cycle then it's an entity. You know it has an ID we treat it as something particularly unique and wonderful and beautiful. People, financial accounts anything that has an ID is an entity. Value objects are objects but they don't necessarily have this identity requirement. They're commodity objects we can pass them as parameters in messages we can pass them attach them as attributes to other entity objects. So for example on most airlines seats are entities. You know they have a particular designation but on Southwest there are value objects because there's no particular designation it's like general admission everybody gets whatever they get all we care about is the number on the aircraft. And finally services. So services are part of the domain model that they're not really objects they're more actions. For example in a trading application we might have an instrument service that goes out and gets the current prices of all the stocks that we're tracking. In our ubiquitous language stocks are instruments. So it's an instrument service that goes out. So the service doesn't maintain state it just goes what it does it fulfills its action and it forgets it waits for the next command. Alright so we have objects that are entities value objects and services. So we have a couple more things to do to implement our domain driven design. So if we don't think about it we might just start taking all these objects and putting them together and clarifying their relationships and sticking them all together and setting them up as a bunch of objects that have whatever relationship. The problem is that part of our application might change one object state at one point while another part of the application changes another object state at a different point. Or if we're being really naughty we might have different parts of the application change the same object state at the same time. So when external parts of our UI application layer start modifying different parts of our domain model at different times it becomes impossible to maintain data integrity. So the solution is to really wrap up related objects based on how closely they're related in our domain model and then give them one point of entry. So external objects can then only reference any of these objects by passing through what we call the aggregate root. So we wrap them up as an aggregate and then all external application logic can only query positions, orders, lots or transactions through the brokerage account. So basically I would say the brokerage account .getPositions and it would give me the collection of positions. And this is actually relatively reflected in the JSON that we're getting back from the server when we query for an account. I'll get an account and it'll have a list of positions and it'll have for each position the number of lots. So it kind of makes sense and that's an easy way on the client side to break that stuff up. But maintaining this integrity key. So once we've got these aggregates we need to manage the life cycle. And we do that through this concept of repositories. So in in Demandrum Design we use repositories to handle kind of the mid-life cycle of our objects. Objects are created, they exist on a server, we're just getting their current state and representing them in the application. So the repository caches that and either serves it back directly on a query or it goes out and gets it from the server. We just kind of like the promises pattern Jeremy showed this morning. It's possible for the repository to know whether it's already gone out and get something and presents the latest version. On a trading application we don't necessarily want to do that because we always want the most current application or the most current data from the server. In Domain Driven Design this is the responsibility of this repository object. But in Backbone our models and collections have fetch methods. So we're not going to fight against that. So one of the things again in Domain Driven Design is that it's a platonic ideal that a repository has this one purpose. But since we've chosen our framework we're not going to fight against that. We're going to use Backbone's model and collection fetch methods and the repository basically just delegates to those as necessary. So the other part of the life cycle of objects we need to maintain is the beginning. How do we create objects and we do that through factories which is again a design pattern getting a four if you're into that sort of thing. So repositories return these already existing objects but the factory creates a new one out of whole cloth. So for instance I have an application that builds cars. And I say new car and I pass in a bunch of attributes that will create a new car object for me. Again you know Backbone can do a lot of this for us. So we have collection.add model.validate to help us build out new objects, add them to our domain model and validate that they're actually correct. So thank you very much Backbone. So this really all just scratches the surface of building domain-driven applications. I haven't actually shown any code so if you're hungry for that again if that's your thing sorry. But in domain-driven design I'd really argue that architecting a complex piece of software that we need to know is more like a philosophical exercise. It comes down more to how we think about the problem and approach it more than how we code it. So when you come across the new application, especially if it's fairly complex don't start coding. You know take a cue from this guy and think about it for a while. I sometimes have to sit on my hands because I really want to like oh this is great, I'll start building this object and that's guaranteed to be a mess. So maybe use domain-driven design, maybe you don't. This is a really quick brief introduction. Maybe use Backbone, maybe you don't. But whatever you do just figure out what you're going to do before you do it and try not to get a mess of code hangers in here. So I'm Bob Bolt, thank you for listening. My slides are available here. The source of the slides are there. And then if you want to really dig into the code of our implementation of that training platform, we have links here. Thank you very much. I think I definitely have time for questions. Do we have any questions for Bob Bolt? So when you're talking to clients and you're trying to understand their business and the processes and all that kind of stuff how does like a visual designing and prototypes, how does that part of the process fit into helping you actually model all that kind of stuff? So ideally when you're developing this domain model and you're talking it out with the client every stakeholder from the client side is there every person who's going to be involved in building the application from visual design to UI design user experience to the developers everyone is a representative at least of everyone is in the room. So when you start talking about this model you know the visual designer has as much input and question asking ability as anyone else in the room and it often helps to have a visual designer there because they're really good at whiteboarding stuff. I can't whiteboard for anything but so I mean everybody who has a stake in this has a voice in this and that's a very important part of the discovery process. Anybody? I think this might come out a little bit messy but here you talk about the repository that's sort of being centralized centralized in the management of fetching domain objects seem very similar to the ones that Brian was emphasizing this morning about not directly calling fetch for instance and having some interface that manages all that for you. I'm just curious if you have any thoughts about the way in which the two approaches are similar or different or maybe not at all too. So unfortunately I miss Brian's talk but the way a repository works in our application is that or would in domain driven design because again in this application we actually want the data fresh every time so we have a method actually let me see if I can just show you so this is the repository actually oh you can't see it there's a lot of stuff in here I actually want to rewrite because I think it's not necessarily correct but basically we have this repository and we have get you know get user, get credentials, get whatever in theory this would either cache so it would go get it if it didn't already exist on the model it would go and get if the collection was empty it would go fetch save that to a cache and then the next time you call this method it would check if it had been cached and then if it hadn't it would go back to the server and return a promise and do it that way so I don't know if that's yeah I don't know so all that would be built in the repository and the repository then would delegate out if it needed to get that data delegate out to the fetch method on the model or reflection in this case thanks let's give it up for Bob!