Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Better Software Design with Clean Architecture

fullstackmark.com

Post reply on HN
Print view View original

111–120 of 141 posts

Re: Better Software Design with Clean Architecture

#111

Post by s73ver »

gloverkcn wrote: post #101
barrkel wrote: post #31

This design puts entities in the middle - everything else pivots around entities. Additionally, it uses the OO approach of implementing logic as methods on the entities. After a couple of decades of experience, I've come to the conclusion that this isn't right. Most business rules involve processes, which are inherently procedural, or, from another perspective, functional - functions of the whole state of the system…

I agree. After 20 years of experience I realize "Clean Architecture" will break down on larger systems. It's easy to create a clean looking architecture with a limited set of use cases. You can do it using any design methodology. Where systems breakdown is when other viewpoints get added. For this system it might be the following: - Pricing/Invoicing - Prerequisites - Academic Status - Professor assignment - Course R…

I think a big part of that is this mistaken idea that, if you duplicate a single line of code, you've done a terrible, terrible thing.

Sandi Metz did a pretty good talk about this, basically saying we need to think more before we abstract things away because "code duplication". https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti...

Re: Better Software Design with Clean Architecture

#113

Post by UK-AL »

TekMol wrote: post #107
UK-AL wrote: post #68

Earlier quoted context omitted.

You can persist this model using anything you want. You would have some kind adapter/library that handles the persistence. It would take these models, and covert them into your datastore.

How would that work in practice? Would this line stay the same: RegisteredCourses.Add(course); And magically trigger an insert in the database?

The repository pattern in the original example would allow you serailise your objects to whatever datastore you want. His object design isn't that great for being persistence ignorant though. I would instead do something like this.

    Course - Aggregate Root

    Student - Aggregate Root
        RegisteredCourse[] - RegisteredCourses - An array objects with date time of registration, and id reference to course.
The method for adding a course would simply create a new RegisteredCourse and place it in the registered courses array.

_studentRepository.save(student) would be a simple matter converting this in memory representation into sql.

I'm not big fan of using lazy loading, and direct references to other aggregates inside of other aggregates. This makes mapping these models without ORM difficult.

Re: Better Software Design with Clean Architecture

#114

Post by andreasgonewild »

penetrarthur wrote: post #104
andreasgonewild wrote: post #82

Earlier quoted context omitted.

We are all here to express our creativity, that's priority #1 and the only reason we ever went anywhere but in circles. I don't mind descriptive names; these names are not descriptive, these names are part of the process. This is how you really do it: 1) start from the problem you are trying to solve, 2) solve the actual problem in the easiest way possible to get experience, 3) improve the solution until it says exac…

Most of the programming problems have been solved before. Some of the solutions turned out to be solid programming patterns. Before you write a single line of code, you check if there is a "standard" way of solving the given problem. That way the code is more maintainable and more people will be able to work with your code.

So we've been told. Part of my point here is that code like this is the opposite of more maintainable. Writing code for clueless people to read and understand is a loosing game for everyone, that energy is better used to cultivate skills collectively. This is about not having to differentiate between individuals, about being able to treat a bunch of coders as a code-factory; which is very convenient but neither efficient nor humane.

Re: Better Software Design with Clean Architecture

#115

Post by jl6 »

barrkel wrote: post #31

This design puts entities in the middle - everything else pivots around entities. Additionally, it uses the OO approach of implementing logic as methods on the entities. After a couple of decades of experience, I've come to the conclusion that this isn't right. Most business rules involve processes, which are inherently procedural, or, from another perspective, functional - functions of the whole state of the system…

> So I've come around to the idea that the database is a better thing to put at the centre

In my admittedly limited experience, applications come and go, but data lasts forever. So I find it unusual when a database is not at the heart of business software.

Re: Better Software Design with Clean Architecture

#116

Post by jstimpfle »

olau wrote: post #85
jstimpfle wrote: post #48

Earlier quoted context omitted.

I've come to avoid OO and use only freestanding functions where possible mostly because of this problem. So often it ends up in a syntactic distinction that is absolutely meaningless otherwise. I use some OO to make abstract datatypes in languages that are inherently OO, but I think the explicit virtual table approach in C or the type classes approach in Haskell are much cleaner. Lately I had to make a REST API which…

Ah, REST. An API is there because someone in the other end wants to do something. If you don't design it but just slap REST on top of your data, then you're not doing that person a favour.

Well you can still "design REST" on top, right? But it could mean some duplicated efforts.

Actually, after having tried a few times, I'm pretty sure I don't want to put REST ideas at the center of my architecture. You just happen to need a network transport, and not even in all cases (debugging for example). And an existing model is never going to be able to represent all the concepts of your application domain. This means that you need to build your own representations.

In theory there is a point of using a standardized object protocol which can represent some CRUD use cases. But from my limited experience I think it breaks pretty quickly, to the point where I can use only GET and POST.

Using protocol layers of increasing specificity may make it easier to use existing tooling with data exchanges. For example, many APIs use HTTP statuscodes as a more coarse-grained version of the return codes in the body (in an ad-hoc format). Also caching is often brought up as an example where you want to buy in to a standardized protocol.

But some APIs don't buy in, like Facebook, which reportedly returns 200 OK always. It seems like a lot of best-effort work with little returns to me as well. But I don't know - I'm not a professional business software guy.

Re: Better Software Design with Clean Architecture

#117

Post by Quarrelsome »

UK-AL wrote: post #84
Quarrelsome wrote: post #78

Earlier quoted context omitted.

They're currency because when you buy something from a shop your money doesn't start telling you what you can and can't do and it travels all the way through many layers of worlds. It is the core and its a good word, use it. I make a career out coming to companies that should have (according to you) made radically different systems but didn't. Most companies don't find it economically justifiable to re-write based on…

"Most companies don't find it economically justifiable to re-write based on slightly different customer requirements and most companies have many deployments," Then don't. Make the domain model customisable with various options. Having specific methods for specific companies seems a lot worse. I build SAAS applications which have various customization options customers can do. I don't really have a problem with it. I…

I do more enterprisey stuff so our customers are a little less accepting of model restriction. I find a service based architecture more flexible as its pretty easy swap out services that just work off a common currency that define different or customisable behaviour. The sort of situation where an entity is performing business logic makes that harder do as opposed to swapping out the service.

I made the same mistakes as OP and learnt the hard way. I encourage you to explore a greater purity in your models in the future because I genuinely believe it leads to better code.

Re: Better Software Design with Clean Architecture

#118

Post by TekMol »

UK-AL wrote: post #113
TekMol wrote: post #107

Earlier quoted context omitted.

How would that work in practice? Would this line stay the same: RegisteredCourses.Add(course); And magically trigger an insert in the database?

The repository pattern in the original example would allow you serailise your objects to whatever datastore you want. His object design isn't that great for being persistence ignorant though. I would instead do something like this. Course - Aggregate Root Student - Aggregate Root RegisteredCourse[] - RegisteredCourses - An array objects with date time of registration, and id reference to course. The method for adding…

Can you show in real code, what you mean? From the text you wrote, I cannot grok it.

Re: Better Software Design with Clean Architecture

#120

Post by jstimpfle »

UK-AL wrote: post #87
redy wrote: post #43

Earlier quoted context omitted.

Registration is definitely not a property of the student. It's always a good idea in these situations to appeal to real life. The actual business will point the way of the business simulation. In the real world we don't ask students to register for a course. Instead students ask the Registrar to register for a course. When the Registrar makes her decision she considers far more than just the internal state of the Stu…

This guy has been thinking about this properly.

Take this thinking to the end and realize that it leads to freestanding functions. In general all the context of the program is needed to execute a functionality. It's not like the registration office owns all the students. It's not like a registration wouldn't change the student's context. Students are both an independent and related concept. The proper object to call most things on is a "Global" object. Now instead of

    Global.do_some_thing(foo, bar)
just

    do_some_thing(foo, bar)
There you have it. OO is an unsound approach which survived so long mainly due to the perceived real world "analogy" and because the Object-Verb-Predicate syntax simplifies code completion.
Post reply on HN