Live data from Hacker News

Software Architecture Patterns: 5 minute read

orkhanscience.medium.com

61–70 of 73 posts

Re: Software Architecture Patterns: 5 minute read

#63
post #51

You don't start by choosing an architecture. You start by understanding the problem and the pieces in the solution space. You then figure out how those pieces can work together to solve the problem. After that you can see the system as nested subsystems and interactions, which you can draw as diagrams and call it an architecture. So I see "architecture" more as a teaching and communication technique, applied after th…

Don't pick the right tool for the job, pick the right framework which secures you extra work for being a tool. - @iamdevloper ... via https://github.com/globalcitizen/taoup

Re: Software Architecture Patterns: 5 minute read

#64
post #51

You don't start by choosing an architecture. You start by understanding the problem and the pieces in the solution space. You then figure out how those pieces can work together to solve the problem. After that you can see the system as nested subsystems and interactions, which you can draw as diagrams and call it an architecture. So I see "architecture" more as a teaching and communication technique, applied after th…

> You don't start by choosing an architecture.

It really depends. Some patterns might be specific to problem domains, but a layered architecture applies pretty much across all types of software projects.

Between defaulting to a layered architecture and just mindlessly piling up ad hoc decisions without any coherent criteria, a layered architecture always wins.

Re: Software Architecture Patterns: 5 minute read

#65

They are better explained here: https://www.oreilly.com/content/software-architecture-patter...

Definitely not a 5min read though

But on the other hand, you cannot really expect a full explanation of software patterns in 5 minutes.

Re: Software Architecture Patterns: 5 minute read

#66
post #64
post #51

You don't start by choosing an architecture. You start by understanding the problem and the pieces in the solution space. You then figure out how those pieces can work together to solve the problem. After that you can see the system as nested subsystems and interactions, which you can draw as diagrams and call it an architecture. So I see "architecture" more as a teaching and communication technique, applied after th…

> You don't start by choosing an architecture. It really depends. Some patterns might be specific to problem domains, but a layered architecture applies pretty much across all types of software projects. Between defaulting to a layered architecture and just mindlessly piling up ad hoc decisions without any coherent criteria, a layered architecture always wins.

Honestly - a layered approach ends up paying dividends even if used solely for code organization. Options like microservices and event frameworks work quite well when using layered approaches internally.

Basically, I've seen SQL in controllers and I don't ever want that again.

Re: Software Architecture Patterns: 5 minute read

#67
post #33

who is doing Space-based architecture?

This part was confusing and possibly useless. The source oreilly article (https://www.oreilly.com/content/software-architecture-patter...) cites a web browser-based auction site. That doesn't sound very "data decoupled" to me when each browser needs up-to-the-second updates on bids.

Re: Software Architecture Patterns: 5 minute read

#68
post #66
post #64

Earlier quoted context omitted.

> You don't start by choosing an architecture. It really depends. Some patterns might be specific to problem domains, but a layered architecture applies pretty much across all types of software projects. Between defaulting to a layered architecture and just mindlessly piling up ad hoc decisions without any coherent criteria, a layered architecture always wins.

Honestly - a layered approach ends up paying dividends even if used solely for code organization. Options like microservices and event frameworks work quite well when using layered approaches internally. Basically, I've seen SQL in controllers and I don't ever want that again.

depends, some systems are such that all they are doing is pumping SQL results into JSON, in that case, I don't want to see some general purpose programming language in the controller. Which is kind of the idea behind https://postgrest.org/ ( written in haskell if anyones interested )

Re: Software Architecture Patterns: 5 minute read

#70

Earlier quoted context omitted.

Depends what "disconnected" means. Before Object Relational Mappers came along, you wrote a load of SQL in Stored Procs or in some other framework. This was super tight coupling because updating the database version could ruin everything. Not everything was in compiled code, so it was hard to track. If you use an ORM (such as Entity Framework I'm about to mention but there are lots) for the write/mutation part then t…

I usually create "Service" classes in the domain layer, which use Repositories. These repositories are a wrapper for the DbContext to allow unit testing. Where do you put your domain logic? Do you have a domain model or is your persistence model your domain model?

Domain model is the peristence model. Splitting them apart is often known as an anemic domain model (in Domain Driven Design).

All the domain logic is on the entity. So our command handlers (akin to your service methods) look like:

1. Load entity 2. Call method on entity, passing in data 3. Save entity 4. Raise events

So we only unit test 2. because that's the domain code. Loading entities from the dbContext is someone else's code. So is saving. So is raising events.

If your entity class gets big, split out the functionality into other classes so that you end up with a fair portion of bodyless methods.

Hope this is making sense!

Post reply on HN