Untangling Your Pattern Addled Thinking

This is free: http://www.infoq.com/minibooks/domain-driven-design-quickly

Give it a try.

You will find out not only that most of this terminology comes from Domain Driven Design, but also how these things are connected together.

What are your thought processes when deciding the best way to go about things?

By not overthinking it.

Patterns in and of themselves are not the design of your code, they are merely guides. You cannot really begin constructing your code by worrying about what patterns make the most sense ahead of time.

First you have to write some code that works and does what it needs to. That's ALWAYS the first step. The less experience you have, the smellier that code will be. That's fine though. But you have to do immediate refactoring. IMMEDIATE, not "eh, I'll get to it later" because then you won't.

So get some code written that solves a business problem, and then smell it. If it smells kind of nasty, it probably is kind of nasty. So refactor it. At the end of the day you only have three "simple" goals to worry about:

1. Your code should do what it's supposed to do
2. Your code should be easy to read and understand, simple to follow etc
3. Your code should be easy to change without a cascading avalanche of code breakage or needing to change it in lots of places.

Every piece of code you write, measure it against those three criteria. You'll find that you'll naturally start implementing common patterns and principles to achieve those three things in the process.

@psampaz Thank you, I'll have a goosey gander at that link this evening.

@tag Sound advice and thanks.

@psampaz That was an eye opening read, thanks again.