Live data from Hacker News

Software Architecture Patterns: 5 minute read

orkhanscience.medium.com

51–60 of 73 posts

Re: Software Architecture Patterns: 5 minute read

#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 the fact. Altho since we're always moving between the details and the big picture, having organized abstractions (ie an architecture) in mind will help keep the design clean.

The architecture evolves and sharpens as a system comes together. And this evolving architecture provides the team with a common terminology and overall direction.

But you rarely start by choosing a specific architecture. Unless you already know a lot about your solution.

Re: Software Architecture Patterns: 5 minute read

#52

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?

Can you expand on how those repositories are written and how you use them for unit testing?

Re: Software Architecture Patterns: 5 minute read

#53

What I nerver understood: * How to disconnect the domain model from persistence. Some solutions add the OR Annotations to the domain model. Some other map the domain model to persistence with a Mapper-layer. But all of them have some constraints. For e.g. on a web api I receive a dto, map it to a domain model, map it to a persistence model and vice versa. Not much gained imho. In this example I would add the OR-annot…

I'm building an application in this fashion at the moment in Go, and honestly, I think it's kinda painful. At some point I already merged the persistence with the domain model, so it's just the domain model with SQL related struct tags. I am tempted to merge it with the HTTP model as well, add JSON tags to it. But everyone is telling me it's a bad idea, so I'm really not sure. A more convenient way to copy properties…

All you need is a little conversion function which takes a domain struct and converts it to a DB struct with tags (for example)? Unless it's a very complex entity multiple levels deep, I usually don't find it all that painful. What is it about DTO conversions that makes it painful for you? Being boilerplate, it's probably not very aesthetically looking, but it usually doesn't take more than a minute to write the conversion function.

Re: Software Architecture Patterns: 5 minute read

#54
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…

> But you rarely start by choosing a specific architecture. Unless you already know a lot about your solution.

That's how it probably should be, but in my experience it rarely is. Generally, businesses decide that they need to re-/implement x, then the enterprise architect shows up and decides on the pattern and then the developers are required to somehow make it work, even if it objectively doesn't.

Re: Software Architecture Patterns: 5 minute read

#55
post #54
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…

> But you rarely start by choosing a specific architecture. Unless you already know a lot about your solution. That's how it probably should be, but in my experience it rarely is. Generally, businesses decide that they need to re-/implement x, then the enterprise architect shows up and decides on the pattern and then the developers are required to somehow make it work, even if it objectively doesn't.

I guess theoretically if the enterprise architect knew about the project and its requirements, the pattern should probably have matched the intended outcome...

Re: Software Architecture Patterns: 5 minute read

#56
post #54
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…

> But you rarely start by choosing a specific architecture. Unless you already know a lot about your solution. That's how it probably should be, but in my experience it rarely is. Generally, businesses decide that they need to re-/implement x, then the enterprise architect shows up and decides on the pattern and then the developers are required to somehow make it work, even if it objectively doesn't.

These patterns are so vague and high-level that you could just throw a dart in one of them and it'd work OK for whatever some company is doing. Almost no one is solving issues that can only be described in one pattern.

If anything people are too caught up in the idea that there decisions are make or break for a business.

Re: Software Architecture Patterns: 5 minute read

#57

Earlier quoted context omitted.

I'm building an application in this fashion at the moment in Go, and honestly, I think it's kinda painful. At some point I already merged the persistence with the domain model, so it's just the domain model with SQL related struct tags. I am tempted to merge it with the HTTP model as well, add JSON tags to it. But everyone is telling me it's a bad idea, so I'm really not sure. A more convenient way to copy properties…

> I am tempted to merge it with the HTTP model as well, add JSON tags to it. If you add a property which shouldn't be public you have to separate them. For example in the domain model you have a user with email but do not want to expose the email. Second argument: I usually create a simple struct for each method. For example I do not want, that they provide the id for post requests. I want to send the id on get reque…

>If you add a property which shouldn't be public you have to separate them. For example in the domain model you have a user with email but do not want to expose the email.

Another possible problem: having to support two versions of the API at the same time.

Re: Software Architecture Patterns: 5 minute read

#58

Earlier quoted context omitted.

> In my book Which book? I see know that one can think of the domain model as most changed layer and if there is a bigger change it is because the domain model changes (e.g. business requirements). So a dependency from the domain model to other parts below are mostly fine.

> Which book? I believe it's used as an idiom. https://dictionary.cambridge.org/us/dictionary/english/in-my...

You are technically correct, the best kind of correct.

Re: Software Architecture Patterns: 5 minute read

#59
post #33

who is doing Space-based architecture?

There's a MMO which uses the approach described in the article. Almost everything happens and is stored in memory, in various independent processing units. Data is dumped to disk only occasionally, in case there's complete system failure (so it's more like a backup). I guess they can afford it because losing some progress in a casual game is not very critical.
Post reply on HN