who is doing Space-based architecture?
Software Architecture Patterns: 5 minute read
61–70 of 73 posts
Re: Software Architecture Patterns: 5 minute read
#62Re: Software Architecture Patterns: 5 minute read
#63You 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…
Re: Software Architecture Patterns: 5 minute read
#64You 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…
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
#65Re: Software Architecture Patterns: 5 minute read
#66You 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.
Basically, I've seen SQL in controllers and I don't ever want that again.
Re: Software Architecture Patterns: 5 minute read
#67who is doing Space-based architecture?
Re: Software Architecture Patterns: 5 minute read
#68Earlier 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.
Re: Software Architecture Patterns: 5 minute read
#69Why is React not in this list?
Re: Software Architecture Patterns: 5 minute read
#70Earlier 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?
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!