A Case For Outside-In Design • Sandro Mancuso • GOTO 2019

This presentation was recorded at GOTO Chicago 2019. #GOTOcon #GOTOchgo

Sandro Mancuso - Pioneer of Software Craftsmanship and co-founder of Codurance

ABSTRACT
For the past few decades, one of the most common approaches to software design has been to first focus on the domain model (application layer), then persistence (data layer) and finally the user interface (presentation layer). But what are the pros and cons of this approach? Are there other alternatives?
In this presentation, Sandro will discuss different design biases and how business analysis can impact architecture. He will then focus on Outside-In Design, explaining how the domain model, bounded contexts and [micro] services can emerge and evolve when driven by the needs [...]

Download slides and read the full abstract here:

#SoftwareArchitecture #DDD #Microserivces

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

[kingscrusher]

Very interesting indeed :). For me as a chess enthusiast as well as a programmer, I find the notion of bias a little analogous to chess playing style throughout the ages. The bias or style of play was largely influenced by the technological, contextual, historical contexts of the time. For example in the Romantic era of chess, there were daring sacrifices and it was thought cowardly not to accept piece sacrifices. The Scientific era saw the improvement in defensive techniques. In IT I think we are in the cloud Era, with huge companies battling for cost effective cloud services. This era influences the style of how sofware is created. So I think the notion of bias is similar to style in that it is within the context of broader technological, social, economic trends. Another bias for example maybe not to consume so many resources for software to be somehow more environmentally friendly - as well as the more standard notions of performance and security biases. Cheers, K

[freddymu]

In general, it's Software Development Lifecycle, Planning, Analysis, Design, Implementation. But with a comprehensive guideline about how to do it, and it's cool! fascinating

[OgnyanDimitrov]

Thank you for presenting this approach. Rich in information and context. Thought-provoking. I like the approach - start with what the business needs and then one feature after another, build and evolve/refactor the system without overengineering. Building in the small while having the big picture (design) also saves a lot of time and effort. Uncle Bob Martins is involved too - nice.

[TristanBailey]

Started as a bit more general guide and then got really good as sharing a stepped process for layers of development

[JonatanMachado]

Sandro ia a very good developer. Thanks for sharing!

[LuccasMaso]

Great methodology, thanks for sharing

[alessandrob.g.]

Have you heard about "Fool-me-once-fool-me-twice" rule? You add the patterns and do a better design in the refactoring fase.