Eric Evans - Tackling Complexity in the Heart of Software

[@WateryIce54321]

Thank you! My takeaways from this are: 1. Collaboratively model the domain so that your software reads like the problem it solves. 2. Isolate your software and establish context in each part of it. There should be enough previously handled assertions that you have a good idea of what's going to happen while looking at any random line of code. (Not sure how to word this one) 3. You don't have to model the domain *exactly*. (Use abstraction to get rid of unnecessary details, and sometimes it makes sense to model things as they are used rather than what they actually are) Some other talking points were more fuzzy to me - particularly around tooling. It's often unclear whether a tool should be used with requirements evolving over time and whatnot. Even though some of my data could be better off in a non-relational DB, maintaining that in parallel with a relational database would be a lot of work. Similarly, it's often difficult to re-design later on, so we often choose some of these initially heavy designs up front because it's costly to revisit later on and/or due to our (or our team's) familiarity with certain designs. Which, as the presenter said, often introduces more complexity than the problem they solve. Bleh, there's so many concerns when thinking about design and tooling.

[@aniketb2010]

16:10: ‘Master the tool first and then focus on the job’. 👍🏻

[@rubenfranco7690]

This man is important!

[@МихайлоСвєчкін]

I would say this man is important for mankind

[@jaanjaan101]

Excellent talk enjoyed it very much!!

[@wilsonlopez697]

Hi cool people... I need your opinion in certain things... I work for a consultancy company and every 6 months (aprox.) we start a new project on our client dependencies... we "try" to work using Scrum but I always talk to the Scrum Master about having the time to know about the bussiness good enaugh to give to our client a good software... for example right now we're on a client where they're trying to implement microservices and they don't even know what context boundries are... so we're trying to "teach" them while we have our Scrum Master on the back of our head asking us to have a MVP to give "value" to our client... Question: What do you guys do dutring the first couple of weeks when a you face a new project like the one I explained before?

[@2002budokan]

Once more, old wine in a new bottle... This is nothing but agile and use case driven clean architecture. Some people prefer to define UCDD and DDD as different things but in fact they are soooo closely related. So much so that when you start doing one, you automatically start doing the other. If you want to write a use case without imposing on any implementation details you should use the domain language hence you should first understand and solve problems in the domain. And very often you discover entities of the domain when you write a use case hence you once more deal with domain vocabulary. Thus DDD is automatically included in your process when you make UCDD, and you model the two inner layers of clean architecture. And when your process is agile, you automatically colaborate with domain experts. That's why my first words were "Old wine in a new bottle".

[@MistaSmith]

There was only Java in 2003???? That seems quite weird. I don't remember anybody porting Linux from Java to C in 2008 or something.