If you see an architecture that has a box or a ring with the word "controller" in it - the design is wrong.
Better Software Design with Clean Architecture
121–130 of 141 posts
Re: Better Software Design with Clean Architecture
#122Earlier 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…
I agreed with the first part of your answer a lot more than the second part.
Re: Better Software Design with Clean Architecture
#123This 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.
Data lives forever. Schemas live short lives.
Re: Better Software Design with Clean Architecture
#124Earlier quoted context omitted.
That codebase sounds interesting, is there a change some parts of it were open sourced?
Unfortunately no :(
Oh wow. I can't be sure, but I'm pretty sure I'm the engineer at Pivotal that you paired with. I definitely remember you making reference to homoiconicity in lisp when we were pairing the day that Clean Architecture really clicked in your head. It was a really cool moment.
There's a lot of engineers at Pivotal, and we have a lot of projects, so maybe I can prove I worked on that codebase by referencing obscure details from it? I remember writing a LOT OF TESTS that used quotes from Wutang Clan and 36 Chambers as strings for names of entities, and a lot of references to 90s hip hop. Was this the same project?
Also, I took some time after our project (and several others) to start a small example of applying Clean Architecture in a toy Go Project, which is open sourced. Maybe check it out?
Re: Better Software Design with Clean Architecture
#125Earlier quoted context omitted.
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…
I believe OO is good for exactly two things: abstract data containers and state machines.
In the former, access hiding cleans up the API and prevents unsafe usages of the container. In the latter, OO enforces a protocol to keep the state machine sealed off and only aware of key inputs and outputs.
And that's it. I've found nothing else. Data itself is better off when strategized to fit in a database, whether off-the-shelf or a custom-tuned, in-memory design. The state machines may need to query a part or all of the database, as well, so their ability to restrict scope only goes so far.
Re: Better Software Design with Clean Architecture
#126This 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 what you call viewpoints are called Bounded Contexts (https://martinfowler.com/bliki/BoundedContext.html) in DDD parlance.
Re: Better Software Design with Clean Architecture
#127It's a shameless plug, but I just have to throw in http://manuel.kiessling.net/2012/09/28/applying-the-clean-ar...
Re: Better Software Design with Clean Architecture
#128Earlier 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…
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.
Re: Better Software Design with Clean Architecture
#129It's so refreshing to see vibrant discussion of how a domain layer should be implemented, when I have practically been run off from teams for suggesting that a domain layer pattern, any domain layer pattern, should be used.
I've seen enormously complex domains implemented as DTOs that are acted duplicately in ORM queries, in PDF rendering, in CSV exporting and then again in CSV importing.
Re: Better Software Design with Clean Architecture
#130I've been using a very similar architecture on an application for about 2 years now, and it's been incredibly smooth to work with, especially in Go (passively satisfied interfaces and enfirced lack of inheritance), though I do feel like the article overcomplicates the design (also recommend looking up onion architecture).
Basically, for me, it boils down to the following:
1. Create domain package(s) with the basic business entities (users, vendors, products, etc) - can't import anything. 2. Create usecases package(s) that acts on these objects and can import anything in the domain package, but nothing else (though can accept repository store interfaces). 3. Create infrastructure packages for taking to databases, caches, etc - can't import from rest of application. 4. Build repository stores to translate between repositories and domain objects (can import domain and usecases, and accepts interfaces for infrastructure). 5. Add controllers/main packages that build repository dependencies with infrastructure config, and pass those interfaces into usecases that do the necessary work and spot back results (imports everything).
The end result is a bit topsy turvy to get used to at first, but then it's a dream. Extremely easy to test (very little dependency coupling in each package), and the most complex parts of the application logic are totally isolated from the complex parts of the infrastructure, so you end up with less cognitive load when dealing with either.
After my experiences so far, I can't see ever switching back to "top down" architecture instead of "inner out" when given a choice.