Desarrollo guiado por el dominio (DDD) con Backbone

Extracto de la transcripción automática del vídeo realizada por YouTube.

thank you everyone so today I'm talking to you about domain carbon web applications using backbone cool before before we get into what that means the signal at this picture because I think this is actually a really good metaphor for software development

so if you look off in the distance here you'll see this ship that's just been launched and it's sailing away but 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 all of the same way like we built 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 st. architecture that helps manage the constant turnover 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 some of the talks today about test-driven development and

dependency injection and then how we we architected our applications you know if we've implemented all the stuff static code analysis testing building so why don't you do so many of our applications still look like files of coat hangers they might

be well modularized piles of coat hangers but there's 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 bubble as Adam mentioned i work at beaucoup

but before joining boku i worked at a large consulting firm specializes 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 you

know trainers want to be able to make trades from the golf course on our iPad we need web applications that can handle that so what we wanted to do is we use what we call the 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 you know importance to our clients and they need data integrity and stability so but before we go any further let's let's be really clear I'm not saying this

is the one way to build applications this is a strategy is particularly suited to large data centric applications other approaches really are equally valid we're going to see very different approach tomorrow with Cujo just pick whatever architecture suits

your particular application schemes but please pick something but right now we're talking about domain driven design so this book came out in 2004 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 you know 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 today we're just going to cover the basics so what is the manger of a 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 domains the universe of actual securities and real life exchanges and people on the training floor who are actually trading these things so domain-driven design is an architectural pattern that places primary focus on this domain in its real

world logic DVD offers a collection of principles and techniques best practices all sorts of things that help us manage these complex applications that are built on this domain but the question comes up you know 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 don't you don't have the time the budget the team capable of pulling

this off if you're not building that complex and application so in short you just make it work so 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

[ ... ]

Nota: se han omitido las otras 2.335 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.