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

101–110 of 141 posts

Re: Better Software Design with Clean Architecture

#101

Post by gloverkcn »

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 Reviews / Social Media
All of these viewpoints are close enough to the registration system that there is a bias towards reusing as much existing code as possible.

The problem is that at a high level two viewpoints look 95% similar, but in the code it equates to creating interdependencies between all of the viewpoints.

Different teams might be successful in keeping the separation in the system, but in most systems I've seen the entanglement starts in the database with the entities. Columns that become nothing more than status flags for different viewpoints. Columns with near identical names that mean almost the same thing, but are handled differently because the viewpoints treat them differently.

When the system gets big enough, a developer cannot mentally map the whole thing. When implementing a feature they will look for what is available vs what the architect had in mind.

This is how you wind up with 10 different getCourse calls all of which are building off one another with various parameters. The code will have a lot of if/thens checking the parameters to make it work for a particular viewpoint and avoids bugs for the others.

The more separation you have between the viewpoints the better. I now prefer separate entities/databases for every viewpoint. There is a set of entities common to all, but these are fact level entities. A course, A student, A professor, An admin, A TA. The entities should contain no status.

Where the viewpoints need information from each other they should just query the appropriate viewpoint, or have the source viewpoint send out updates (great place for event sourcing).

It might sound like I'm describing micro services. I wouldn't argue that, but I would say that a viewpoint is a higher level concept than a service. A viewpoint could be a collection of micro-services, or a single system (using this Clean Architecture).

Re: Better Software Design with Clean Architecture

#102

Post by andreasgonewild »

hasenj wrote: post #96
andreasgonewild wrote: post #42

You know someone is certified when you have to scroll code sideways because the names don't fit the screen. I thought we already agreed that process is the opposite of progress? I mean come on, RequestCourseRegistrationInteractor, who are you trying to impress here? These processes were designed to turn humans into machines; to decrease the dependence on creativity and skill at the cost of additional effort and compl…

I think you are opposing it for the wrong reason. There should not be a lot of room for creativity when implementing specific business rules. The goal should be clarity and readability. These convoluted patterns obscure the logic and confuse the reader with their pointless abstractions.

I think you are confused. The whole point of software is to create something that didn't exist before, building the same software over and over again doesn't make any sense. I'm not talking about creativity in interpreting business rules, I'm talking about creativity in building software.

Re: Better Software Design with Clean Architecture

#103

Post by unclebucknasty »

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've come around to the idea that the database is a better thing to put at the centre

I've seen systems that take this to the extreme of not allowing a single piece of logic into the domain. Domain objects were essentially data containers only. So, if you had a Person object with firstName and lastName properties that represented those DB columns, then even a getFullName() that concatenated the two was verboten.

Instead, all logic had to be in a service. This led to lots of duplication and a super-massive service layer in a system that was decidedly procedural, even if it was implemented in an OO-language.

Re: Better Software Design with Clean Architecture

#104

Post by penetrarthur »

andreasgonewild wrote: post #82
penetrarthur wrote: post #81

Earlier quoted context omitted.

Who have you agreed with? Software has to be predictable and easy to maintain. It is great if you can predict what the class does based on its name. It is also great if you know what you have to search for based on the name of pattern. Software is there not to express the creativity of a given programmer, but rather to meet the requirement of the technical tasks.

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.

Re: Better Software Design with Clean Architecture

#105

Post by maxxxxx »

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 have also concluded that a lot of business processes can't easily be modeled by objects. There are almost always a bunch of exceptions that need to change change data directly .

Re: Better Software Design with Clean Architecture

#106

Post by mattgreenrocks »

jdmichal wrote: post #83
saltedmd5 wrote: post #58

Oh look, more kludgy over-designed enterprise gumf. When are people going to learn that if you just start with the entry point with granular components, letting each define the interface for its dependencies, you get a much nicer, looser, more flexible structure than these enterprise "patterns" that ultimately all just turn into a big ball of mud? Stop pretending you can design codebases.

People forgot at some point that design patterns are for solving problems. The key being that you should only be solving problems you actually have, and stop making up imaginary problems in your head before you even start coding. My code is typically some dumb data objects, static functions to apply rules to that data, and a bunch of interfaces for abstracting external dependencies. The code that ties everything toge…

I know this is written as OO, but it is very functional in style. Keeping IO as far away from entities and business rules goes a very long way in easing maintenance. However, sometimes you need to do IO in your business rules, which necessitates interfaces for mocking.

IMO, this general idea is very powerful for most code. I believe algebraic effect systems will popularize it further by making it a natural pattern. While OO should be written in this way, we are currently in this weird period of programming history where we don't talk about practices and design as seriously as we should.

But, I'm glad you mentioned this approach. It is not hard to understand, it is elegant, and it is as simple as can be. Just requires a tiny amount of glue and forethought.

Re: Better Software Design with Clean Architecture

#107

Post by TekMol »

UK-AL wrote: post #68
salex89 wrote: post #56

Earlier quoted context omitted.

Actually, very similar, since Entity Framework is usually used. Sources implement the IQueriable interface which lets you write queries with method chaining or LINQ. To be honest, it kinda looks better than it is. In reality I find it produces sub-optimum performance and a lot of things can not be done without spilling query logic to the app. Not to mention a lot of linq/method chaining queries cannot be translated t…

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?

Re: Better Software Design with Clean Architecture

#108

Post by mattgreenrocks »

tiogemini wrote: post #95
jdmichal wrote: post #83

Earlier quoted context omitted.

People forgot at some point that design patterns are for solving problems. The key being that you should only be solving problems you actually have, and stop making up imaginary problems in your head before you even start coding. My code is typically some dumb data objects, static functions to apply rules to that data, and a bunch of interfaces for abstracting external dependencies. The code that ties everything toge…

What are the disadvantages?

You need to write more structure than if you had simply just put all the code in the web handler or whatever. You also need to be able to abstract all DB/API calls if you want to test easily, as mocking things you don't own just leads to pain later on.

Re: Better Software Design with Clean Architecture

#110

Post by coldtea »

pegasus wrote: post #26
coldtea wrote: post #14

Earlier quoted context omitted.

> Also, the concentric circles did nothing for my way of thinking, as messages are linear - they start from a place, and they end in a place. Thus a stack was a lot easier for me to digest than these concentric circles. Messages might be linear but scopes are encompassing inner scopes. Encapsulation is not usually depicted as a stack. > And finally, the ambiguous language. Why should I care that there are enterprise…

As an aside: according to wikipedia, there are no recorded deaths from ingestion of Amanita Muscaria. It's not really a poisonous mushroom, though it can have intense psychoactive effects when taken in large quantities.

>As an aside: according to wikipedia, there are no recorded deaths from ingestion of Amanita Muscaria.

Well, the Wikipedia lemma puts it this way:

  Although classified as poisonous, reports of human deaths 
  resulting from its ingestion are extremely rare. A fatal 
  dose has been calculated as 15 caps.[55] Deaths from this 
  fungus A. muscaria have been reported in historical journal 
  articles and newspaper reports,[56][57][58] but with modern 
  medical treatment, fatal poisoning from ingesting this 
  mushroom is extremely rare.[59] Many older books list 
  Amanita muscaria as "deadly", but this is an error that 
  implies the mushroom is more toxic than it is.[60] The 
  North American Mycological Association has stated that 
  there were: "no reliably documented cases of death from 
  toxins in these mushrooms in the past 100 years".
Post reply on HN