The Principles of Clean Architecture by Uncle Bob Martin

How To Design A Good API and Why it Matters [0] The Principles of Clean Architecture [1] The State of the Art in Microservices by Adrian Cockcroft [2] "The Mess We're In" by Joe Armstrong [3] [0] [LINK] [1] [VIDEO] [2] [LINK] [3] [LINK]

1) Do not attempt to live code. change your code via version control, build small videos, copy and paste... whatever you do... do not try and live code 2) Read "The presentation secrets of Steve Jobs" ... its not really about Steve Jobs so much as its about how to be a great presenter. 3) building or writing a talk is significantly less important than the delivery... which means that more of your time should be spent on how to deliver the speech (recording I find is the best way to practice) 4) Pick a single thing and do it well, do not attempt to put too much into a talk or tackle something massively complex. 5) Make sure that everyone is walking away with something they can actually use. This doesn't require it be a hard skill... "Soft" or philosophical utilities are just as good 6) Have Fun and be funny... Speakers have a tendency to want to show off the size of their intellect, and the level their competency- having a speech be entertaining is way way more important. 7) DO NOT READ FROM YOUR SLIDES. know your shit. slides are supplementary Extra Credit. Here's a collection of some fantastic technical speeches: * [LINK] * [LINK] * [VIDEO] * [LINK] * [LINK] * [LINK]

I don't think there's a one-size-fits-all solution to this, since different domains require different guarantees from your storage medium. For example, if you need to combine multiple actions with a certain level of transaction safety, defining an interface for that can get tricky. Overall, I tend to agree with Uncle Bob's "Clean Architecture" [1][2] approach when it comes to DBs, though: The DB usually (rembember that there is an exception to every rule!) has no business of being the "center" of an application. It should provide you with functionality, not dictate how your business logic works. If you can pull out your DB and give it a sensible interface, you still might end up having a lot of inline SQL queries, but they are not littered all over your codebase; they live inside a narrow scope (a plugin, say). Also, the SQL schema and queries in this case often are quite boring -- the tricky bit is coming up with a good interface that provides all the guarantees you need to uphold (complicated transactions maybe?). And remember that you need these guarantees because of how your business domain works, not because of your DB. Perhaps you can get rid of some of them if you organize your storage (i.e. DB) in a specific way? [1]: [LINK] [2]: [VIDEO] Edit: Also note that there's no reason not to use a ORM in this way, too (if it suits you). The important part is the same: The ORM has no business dictating how your business logic should be implemented, and if you try to remove it f

I'm not fully on board with all of Roberts views but this point about a framework for frameworks sake is one I agree with. [VIDEO] starting at around 10:30 he gets into what I was getting at. > Whereas I'd say Laravel and it's ecosystem are far more productive and time saving than simply using just PHP. I'm not arguing a time thing. I'm arguing that a framework that forces its architecture onto your domain model is fundamentally broken by design. My domain should drive architecture choices and the framework should let me augment that with well worn libraries and modular patterns. Laravels architecture works for one thing: web sites. And for that, you're better off using WordPress. Laravel is better than older frameworks, like say, code igniter but it still fights you every step of the way if you want to step outside the box.

For some perhaps-off-topic contrarianism, what do you make of Uncle Bob railing against database-oriented architectures? [0] (He takes a good few minutes to get his point across.) [0] [VIDEO]

Mvc isn’t an architecture at all. It’s just meant to be a tiny pattern for ui widgets from the 70s that people started to use as an architecture. The actual goal is to just keep a tiny piece of business logic from having a dependency on a specific input or on the view. It applied to a single button or a single input field back then. Architecture is more about deciding what direction your dependencies go and where your hard boundaries go [VIDEO] (approx 27 mins in)

I don't think DDD is a silver bullet; building quality software will require DDD but it will also require more. But don't get me wrong, I always been a proponent of keeping Domain concerns in The Domain layer. It makes much more things easier in the long run, beginners should be exposed to DDD very soon in the learning process, in my opinion. DDD and the principle of separation of concerns always reminds of Uncle Bob screaming "DATABASE IS DETAIL!": [VIDEO]