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

71–80 of 141 posts

Re: Better Software Design with Clean Architecture

#71

Post by bsaul »

IMHO, the most important thing in architecture are the concerns and goals of the architecture. Not the particular architecture itself. A single architecture can't check all the marks, or you end up with a monster. The job of an architect is to identify the main risks and pain point of a particular system, and adapt the structure of the project to address them best.

"Enforcing separation of concerns" is a good one. But so would be "identify the various runtime threads of your system easily", or "minimize code surface responsible for mutation of shared data", or "decouple configuration primitives from the components themselves".

Those concerns are more or less important depending on your use case. MMORPG server code or regular desktop app, or mobile webapps sold as templates, all have very very different concerns, so i dont think it would make sense to use a single architecture as a template for every problem.

Re: Better Software Design with Clean Architecture

#72

Post by UK-AL »

konschubert wrote: post #70
mbrock wrote: post #57

Earlier quoted context omitted.

If I say "students can be registered for courses in the school" then you might think the OO model should be school.register(student, course) which does actually seem reasonable to me. Here the school object would basically be the system's logic as a whole, and both the course and the student could just be IDs. I really think single dispatch OO is a huge distraction and I haven't seen any strong arguments for its use…

If the pairings of courses and students are registered in the school object, then that's basically OO implementation of a many to many relationship of students and courses. That's why I like Django. You just tell it that you want a many-to-many between students and courses and it does they for you, symmetrically, without forcing you to introduce a class such as "school".

Bi-directional models come with their own problems.

Re: Better Software Design with Clean Architecture

#73

Post by Quarrelsome »

UK-AL wrote: post #69
Quarrelsome wrote: post #67

Earlier quoted context omitted.

CourseRegistration.Register(course, student); CourseRegistration.ViewCoursesFor(student); I think giving either entity "ownership" of the relation is a disaster waiting to happen. I just have this vision of someone wanting data about students accidentally loading all the course information. In the DAL of course you end up modelling however but seeing courses in a student just makes me ill.

In this case it isn't that bad since its only loading registered courses for that specific student. Which for a student would be limited(10?). In fact it should probably be a business rule inside RegisterForCourse that a student can only register for a specific amount of courses per semester. You normally need load an entire aggregate, so that you can maintain your invariants. If you separate into 3 aggregates such a…

I just think its bad because its asking the student to be involved in the process of registration. I don't think that way of thinking scales. Unless you're making a util (which enables any architectural practice tbh) you're gonna eventually get stung if you pollute your currency with logic. Currencies just like graphical interfaces should be as dumb as possible.

One day someone is going to want slightly different rules for student course registration and then they'll realise this rule is baked into the core and that's sad.

Re: Better Software Design with Clean Architecture

#74

Post by UK-AL »

Quarrelsome wrote: post #73
UK-AL wrote: post #69

Earlier quoted context omitted.

In this case it isn't that bad since its only loading registered courses for that specific student. Which for a student would be limited(10?). In fact it should probably be a business rule inside RegisterForCourse that a student can only register for a specific amount of courses per semester. You normally need load an entire aggregate, so that you can maintain your invariants. If you separate into 3 aggregates such a…

I just think its bad because its asking the student to be involved in the process of registration. I don't think that way of thinking scales. Unless you're making a util (which enables any architectural practice tbh) you're gonna eventually get stung if you pollute your currency with logic. Currencies just like graphical interfaces should be as dumb as possible. One day someone is going to want slightly different rul…

"One day someone is going to want slightly different rules for student course registration and then they'll realise this rule is baked into the core and that's sad."

This is a desirable trait, and one of the main points of DDD. If you want to change registration, you change the core business logic. It then applies to all applications using that business logic. If you have a real business case for different registration methods, then you simply model that on your entities.

If you don't do this, your going to get business rules applied inconsistently as programmers will interpret requirements slightly differently.

Re: Better Software Design with Clean Architecture

#75

Post by heartbreak »

threeseed wrote: post #29
coldtea wrote: post #16

Earlier quoted context omitted.

> Surprising this has been written in 2017. It looks like java written a decade ago. Because good architecture has somehow evolved? > This can be a kind of organizational solution much like microservices to separate concerns. This is orthogonal to microservices. And microservices aint but one model of creating applications, not "THE 2017 model".

> Because good architecture has somehow evolved? Of course. Every year gives us greater insight into what approaches work and don't work. Which is why we have seen Java technologies like EJB, JCA, JTA, OSGI, JSP etc generally fall by the wayside in favour of less convoluted and less architecturally heavy approaches. > And microservices aint but one model of creating applications, not "THE 2017 model". Microservices a…

> Microservices are unquestionably the defacto standard

There's a wide world of software out there that you have yet to explore.

Re: Better Software Design with Clean Architecture

#76

Post by Quarrelsome »

UK-AL wrote: post #74
Quarrelsome wrote: post #73

Earlier quoted context omitted.

I just think its bad because its asking the student to be involved in the process of registration. I don't think that way of thinking scales. Unless you're making a util (which enables any architectural practice tbh) you're gonna eventually get stung if you pollute your currency with logic. Currencies just like graphical interfaces should be as dumb as possible. One day someone is going to want slightly different rul…

"One day someone is going to want slightly different rules for student course registration and then they'll realise this rule is baked into the core and that's sad." This is a desirable trait, and one of the main points of DDD. If you want to change registration, you change the core business logic. It then applies to all applications using that business logic. If you have a real business case for different registrati…

Its already been deployed and some customers are relying on the old behaviour. Old clients might need to call new server code. If you've baked your logic into the objects you pass around you've done a stupid as the client definition could give a different answer than the server definition. ENJOY YOUR "CONSISTENCY"!

So what's easier to change? Giving customers versions that give them all different types of the core base type Student or JUST changing the type of CourseRegistration that they visit? (CourseRegistration is a service as opposed to a currency).

You keep your currency CLEAN.

Re: Better Software Design with Clean Architecture

#77

Post by UK-AL »

Quarrelsome wrote: post #76
UK-AL wrote: post #74

Earlier quoted context omitted.

"One day someone is going to want slightly different rules for student course registration and then they'll realise this rule is baked into the core and that's sad." This is a desirable trait, and one of the main points of DDD. If you want to change registration, you change the core business logic. It then applies to all applications using that business logic. If you have a real business case for different registrati…

Its already been deployed and some customers are relying on the old behaviour. Old clients might need to call new server code. If you've baked your logic into the objects you pass around you've done a stupid as the client definition could give a different answer than the server definition. ENJOY YOUR "CONSISTENCY"! So what's easier to change? Giving customers versions that give them all different types of the core ba…

You identify what customers want to customize, and provide a way customizing that. Some customers want 10 courses per student, others 5 courses. You could easily model that in a domain model.

If you want something radically different, then are you even developing the same application anymore?

By the way i've never heard anyone call the core entities of an application "Currency" before, where did you even learn that? I imagine that could be confusing.

I also imagine having an application where you have build custom methods for each customer who wants something slightly different is terrible for codebase maintainability.

Re: Better Software Design with Clean Architecture

#78

Post by Quarrelsome »

UK-AL wrote: post #77
Quarrelsome wrote: post #76

Earlier quoted context omitted.

Its already been deployed and some customers are relying on the old behaviour. Old clients might need to call new server code. If you've baked your logic into the objects you pass around you've done a stupid as the client definition could give a different answer than the server definition. ENJOY YOUR "CONSISTENCY"! So what's easier to change? Giving customers versions that give them all different types of the core ba…

You identify what customers want to customize, and provide a way customizing that. Some customers want 10 courses per student, others 5 courses. You could easily model that in a domain model. If you want something radically different, then are you even developing the same application anymore? By the way i've never heard anyone call the core entities of an application "Currency" before, where did you even learn that?…

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 slightly different customer requirements and most companies have many deployments, not just "one perfect one" that most modellers appear to imagine. If your design doesn't have the flexibility of change designed into it you're going to struggle when you get a second client.

> I also imagine having an application where you have build custom methods for each customer who wants something slightly different is terrible for codebase maintainability.

Yeah of course its a massive pain in the ass but it enables you to sell more.

Re: Better Software Design with Clean Architecture

#79

Post by BoiledCabbage »

grierson wrote: post #17

I been using a very similar pattern [Port and Adapters] http://blog.ploeh.dk/2016/03/18/functional-architecture-is-p... since moving to F#, paired with [Railway Oriented Programming] https://fsharpforfunandprofit.com/rop/ for the 'Adaptper' level and using DDD for modelling the 'Entities' & 'Use Case' layers' and it been working well for me so far. Scott Wlaschin has recently released an [ebook] https://pragprog.com/…

These are all architecture ideas I've been interested in, I'll have to check out the book.

Overall architecture in development is still early on in maturity.

Re: Better Software Design with Clean Architecture

#80

Post by JustSomeNobody »

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.

I always advocate building up a walking skeleton of the system because only then does the architecture begin to emerge. I want to see how the data moves through the system to handle the core functionality; the actual goal of the system. I've sat in too long meetings where someone with their architect hat on spends hours going over this wonderful architecture for Core System Rewrite(tm) and not one time ever mentions the actual CORE functionality the system is trying to model. It's all gibberish about layers and entities and buses, etc. We're building a tire inflater, you have not one time mentioned how it actually inflates tires!
Post reply on HN