6 ms·

I was in the same situation as you a couple years ago. I'd taken programming classes in high school but I was unsure how "real" software was written. So, I sta

I was in the same situation as you a couple years ago. I'd taken programming classes in high school but I was unsure how "real" software was written. So, I started learning about design patterns. In particular, I spent a lot of time reading through this site [1] and "Head First Design Patterns". It was a mistake. I've used maybe 2-3 of these design patterns when actually writing code, and never because I intended to use, say, a factory or a singleton -- I wrote what code I thought was most appropriate and it turned out to match an existing pattern. -- Here's what's more valuable to learn: - SOLID principles - Realizing that what depends on what in your web application matters. You want your business logic depending on your DB access code and your web layer depending on your business logic. You do NOT want your business logic depending on your web layer. - Realizing that your web app is really just some business logic which has a HTTP interface. - Organizing software into layers. In a web app you'd have layers for middleware, controllers, business logic, and database access. - Folder structure. I have a folder for each layer and try to have a descriptive name for each file in it. If a folder is getting messy, add another folder inside it with a descriptive name. - Understand that refactoring is a fact of life. When you start a project, there's no way you can think of the optimal design up-front. This means you'll write code, accrue technical debt, and will need to refactor. Realize that this is 100% normal. [1] https://sourcemaking.com/design_patterns https://sourcemaking.com/design_patterns

thijsvandien 7y ago
You don't want your business logic to depend on anything other than interfaces that it "owns". The actual database access code would be an implementation of such an interface. In other words, the business logic specifies in abstract terms what it needs, and the code surrounding it provides that.
- veeralpatel979 7y ago
  Thank you for this comment; I will keep this in mind. When working with a language like Go, where I have a DB access layer where I'm running raw SQL queries, I agree with this. When working with Rails, though, I typically just make ActiveRecord calls in my service layer; it's simpler.
  - insulanian 7y ago
    How do you write unit tests your service layer then? Unit testing is much more important in dynamic languages, because there's no compiler to protect you from basic mistakes.
ellius 7y ago
Small quibble, I really like inverting the (business logic) –> (persistence) dependency. That way your business logic drives everything, which aligns with your point about the app being "logic with an HTTP interface." Agree wholeheartedly with the rest.
- veeralpatel979 7y ago
  Thanks! Are you suggesting business logic depends on persistence or persistence depends on business logic? How is the second option possible?
  - ellius 7y ago
    The second option is possible if you declare an abstract dependency (preferably just a contract like an interface) and make your persistence layer implement it. I highly recommend "Clean Architecture" if you'd like to learn more about that approach.
labarilem 7y ago
Still, it may prove useful to know the design patterns terminology. In my experience, it helps when discussing with other software engineers and sometimes interviewers ask you question about those patterns.
dangets 7y ago
I am currently a big fan of the hexagonal architecture which is pretty close to what you describe as far as layering. https://blog.octo.com/en/hexagonal-architecture-three-principles-and-an-implementation-example/ https://blog.octo.com/en/hexagonal-architecture-three-princi... https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-a... I also advocate for packaging by feature rather than layer (each feature defines its layers) https://hackernoon.com/package-by-features-not-layers-2d076df1964d https://hackernoon.com/package-by-features-not-layers-2d076d...
- thedevindevops 7y ago
  If you want more literature on that topic, it's usually referred to as Domain Driven Design where I'm from.

thijsvandien 7y ago

You don't want your business logic to depend on anything other than interfaces that it "owns". The actual database access code would be an implementation of such an interface. In other words, the business logic specifies in abstract terms what it needs, and the code surrounding it provides that.

veeralpatel979 7y ago
Thank you for this comment; I will keep this in mind. When working with a language like Go, where I have a DB access layer where I'm running raw SQL queries, I agree with this. When working with Rails, though, I typically just make ActiveRecord calls in my service layer; it's simpler.
- insulanian 7y ago
  How do you write unit tests your service layer then? Unit testing is much more important in dynamic languages, because there's no compiler to protect you from basic mistakes.

ellius 7y ago

Small quibble, I really like inverting the (business logic) –> (persistence) dependency. That way your business logic drives everything, which aligns with your point about the app being "logic with an HTTP interface." Agree wholeheartedly with the rest.

veeralpatel979 7y ago
Thanks! Are you suggesting business logic depends on persistence or persistence depends on business logic? How is the second option possible?
- ellius 7y ago
  The second option is possible if you declare an abstract dependency (preferably just a contract like an interface) and make your persistence layer implement it. I highly recommend "Clean Architecture" if you'd like to learn more about that approach.

labarilem 7y ago

Still, it may prove useful to know the design patterns terminology. In my experience, it helps when discussing with other software engineers and sometimes interviewers ask you question about those patterns.

dangets 7y ago

I am currently a big fan of the hexagonal architecture which is pretty close to what you describe as far as layering. https://blog.octo.com/en/hexagonal-architecture-three-principles-and-an-implementation-example/ https://blog.octo.com/en/hexagonal-architecture-three-princi... https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-a... I also advocate for packaging by feature rather than layer (each feature defines its layers) https://hackernoon.com/package-by-features-not-layers-2d076df1964d https://hackernoon.com/package-by-features-not-layers-2d076d...

thedevindevops 7y ago
If you want more literature on that topic, it's usually referred to as Domain Driven Design where I'm from.