Better Software Design with Clean Architecture • Hacker News Board

Re: Better Software Design with Clean Architecture

#41

Post by mbrock » Mon, Jul 03, 2017, 11:05 AM UTC

UK-AL wrote: post #37

mbrock wrote: post #36

Earlier quoted context omitted.

How did you decide that the registration is a property of the student and not the course?

This is actually a part of understanding the specific domain. How do the educational practitioners think about the problem for application your working on? Is the application student or course centric? This is big part of DDD, and involves working domain experts and getting inside each others heads. You could defiantly model it as the Register method on the course. But this example shows how you can avoid people mess…

I wonder how to even formulate the question to the practitioners -- it seems like an artificial choice imposed by the computer formalism (single-dispatch OO).

In other words, I don't see how it is a domain question, and it seems likely that the domain practitioners just think "there are courses, and there are students, and students can be registered for courses".

My suspicion is that DDD would basically be better without the focus on single dispatch OO.

Re: Better Software Design with Clean Architecture

#42

Post by andreasgonewild » Mon, Jul 03, 2017, 11:06 AM UTC

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 complexity; to enable large groups of unmotivated developers to deliver mediocre software reliably; which makes them sub-optimal for any other use case.

Re: Better Software Design with Clean Architecture

#43

Post by redy » Mon, Jul 03, 2017, 11:08 AM UTC

mbrock wrote: post #36

UK-AL wrote: post #33

Earlier quoted context omitted.

This is solved by DDD and aggregates. Here's how i would do it. Course - Aggregate Root Student - Aggregate Root RegisteredCourses[RegisteredCourse[]) - Sub Entity Collection - with id reference to course. With metadata like date time when the registration occurred. RegisterForCouse Method There should be no mutable public properties, internal methods should be private. Everything should go through an aggregate root…

How did you decide that the registration is a property of the student and not the course?

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 Student; she considers (1) does the course have any available seats? (2) has the Student met all the course pre-requisites and, most importantly, (3) has the student paid his tuition and is he even a valid member of the university community.

What the Student does have is a history and a context -- that is, a state -- that must be considered when registering for courses. The student may also have preferences -- courses he wants to register for.

The language of the business should guide these decisions always. A student submits a request tfor a course and it is the office of that accepts or denies this request.

Re: Better Software Design with Clean Architecture

#44

Post by _pmf_ » Mon, Jul 03, 2017, 11:10 AM UTC

mbrock wrote: post #36

UK-AL wrote: post #33

Earlier quoted context omitted.

This is solved by DDD and aggregates. Here's how i would do it. Course - Aggregate Root Student - Aggregate Root RegisteredCourses[RegisteredCourse[]) - Sub Entity Collection - with id reference to course. With metadata like date time when the registration occurred. RegisterForCouse Method There should be no mutable public properties, internal methods should be private. Everything should go through an aggregate root…

How did you decide that the registration is a property of the student and not the course?

If you are subscribing to the DDD snake oil, you usually weasel out of this decision by claiming that it belongs to the student in one Bounded Context™ and to the course in another.

Re: Better Software Design with Clean Architecture

#45

Post by redy » Mon, Jul 03, 2017, 11:10 AM UTC

mbrock wrote: post #41

UK-AL wrote: post #37

Earlier quoted context omitted.

This is actually a part of understanding the specific domain. How do the educational practitioners think about the problem for application your working on? Is the application student or course centric? This is big part of DDD, and involves working domain experts and getting inside each others heads. You could defiantly model it as the Register method on the course. But this example shows how you can avoid people mess…

I wonder how to even formulate the question to the practitioners -- it seems like an artificial choice imposed by the computer formalism (single-dispatch OO). In other words, I don't see how it is a domain question, and it seems likely that the domain practitioners just think "there are courses, and there are students, and students can be registered for courses". My suspicion is that DDD would basically be better wit…

See my comment below. The language of the business will almost always guide the design in the right direction. There are rare cases where the business is unaware of a more "essential truth." This isn't about OO it's about faithfully capturing the model of the domain which is all DDD is.

Re: Better Software Design with Clean Architecture

#46

Post by TekMol » Mon, Jul 03, 2017, 11:12 AM UTC

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

Same for me.

    I'm not advocating writing all global validations
    in SQL.

What do you mean? Can you give an example?

Re: Better Software Design with Clean Architecture

#47

Post by UK-AL » Mon, Jul 03, 2017, 11:16 AM UTC

mbrock wrote: post #41

UK-AL wrote: post #37

Earlier quoted context omitted.

This is actually a part of understanding the specific domain. How do the educational practitioners think about the problem for application your working on? Is the application student or course centric? This is big part of DDD, and involves working domain experts and getting inside each others heads. You could defiantly model it as the Register method on the course. But this example shows how you can avoid people mess…

I wonder how to even formulate the question to the practitioners -- it seems like an artificial choice imposed by the computer formalism (single-dispatch OO). In other words, I don't see how it is a domain question, and it seems likely that the domain practitioners just think "there are courses, and there are students, and students can be registered for courses". My suspicion is that DDD would basically be better wit…

"students can be registered for course" - This is already implying an order.

Re: Better Software Design with Clean Architecture

#48

Post by jstimpfle » Mon, Jul 03, 2017, 11:16 AM UTC

mbrock wrote: post #36

UK-AL wrote: post #33

Earlier quoted context omitted.

This is solved by DDD and aggregates. Here's how i would do it. Course - Aggregate Root Student - Aggregate Root RegisteredCourses[RegisteredCourse[]) - Sub Entity Collection - with id reference to course. With metadata like date time when the registration occurred. RegisterForCouse Method There should be no mutable public properties, internal methods should be private. Everything should go through an aggregate root…

How did you decide that the registration is a property of the student and not the course?

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 is basically a distributed Object-oriented interface. I think I managed to get it done with compromises, but I'm not happy. Another idea would be to make a procedural interface first and then make a REST API on top if needed. But I have some doubts it can work out practically.

Re: Better Software Design with Clean Architecture

#49

Post by chii » Mon, Jul 03, 2017, 11:17 AM UTC

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…

if only you've gone one step further, and discuss the (imho) cleanest solution - a event store and a query mechanism (aka, event sourcing, and CQRS https://martinfowler.com/bliki/CQRS.html).

When you want to ask questions about the state of the app, you make queries. These queries could be sql - in which case, your app is directly dependent on the type of storage, and is almost un-abstractable. it could be a custom/bespoke query language (where a set of hardcoded api calls to the Db/datastore counts as an api).

The event source system is responsible only for storing facts. Therefore, the "problem" of where the validation of students against courses doesn't exist, because that relationship is a "fact" in the event store (there must've been a registration happening at some point for this fact to exist). Therefore, a programmer _cannot_ make the mistake of accidentally adding a course to a student who didn't register, unless they maliciously do it.

Re: Better Software Design with Clean Architecture

#50

Post by jstimpfle » Mon, Jul 03, 2017, 11:17 AM UTC

UK-AL wrote: post #47

mbrock wrote: post #41

Earlier quoted context omitted.

I wonder how to even formulate the question to the practitioners -- it seems like an artificial choice imposed by the computer formalism (single-dispatch OO). In other words, I don't see how it is a domain question, and it seems likely that the domain practitioners just think "there are courses, and there are students, and students can be registered for courses". My suspicion is that DDD would basically be better wit…

"students can be registered for course" - This is already implying an order.

That's wishful thinking.