51–60 of 141 posts
Earlier quoted context omitted.
"students can be registered for course" - This is already implying an order.
That's wishful thinking.
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…
Practically speaking, I find that abstracting a system into a set of commands and a set of queries (i.e. CQRS) is often the "right" solution. Each command/query encapsulates an individual use-case, and all of the business rules and database access required.
Surprising this has been written in 2017. It looks like java written a decade ago. This can be a kind of organizational solution much like microservices to separate concerns. This is important when collaborating with a large amount of people. Clear boundaries and all that. You pay for those boundaries with a convoluted mess of classes that describe the design pattern rather than the business logic. You end up with Ab…
I think it's hard to really explain why software should be built like this. This is why architects and senior devs and the like often end up ruling by dictat and simply laying down rules like "messages only in the ACL, no messaging in the domain." The problem that Clean Architecture and DDD are trying to solve are architectural and ultimately organizational problems and these problems are not clear to most developers who are just given a story and told to implement some new feature or story. The only hope is to make these these architectural problems everybody's problem. Spread the pain.
Microservices btw are no escape hatch. Microservices that don't get the essential system boundaries right are in fact going to become a horrible mess. If anything microservices make it more important to think carefully about the boundaries and the interfaces of the system.
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/…
Then apply a command to the domain object, then save the emitted events.
They are still entity centric.
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 to the exact same conclusion after spending time with these same types of systems. Practically speaking, I find that abstracting a system into a set of commands and a set of queries (i.e. CQRS) is often the "right" solution. Each command/query encapsulates an individual use-case, and all of the business rules and database access required.
Command side has a domain model, which would be your business objects in this case. A command simply loads the entity, performs a method on it, saves it.
Query has a query model which designed for fast reads, normally built by events emitted by the domain model.
Which language is he using? Is that C#? It looks like this only deals with in-memory data structures. How does stuff get read from / written to the DB?
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.
school.register(student, course)
I really think single dispatch OO is a huge distraction and I haven't seen any strong arguments for its use as a general paradigm.
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.
Earlier quoted context omitted.
"students can be registered for course" - This is already implying an order.
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…
Surprising this has been written in 2017. It looks like java written a decade ago. This can be a kind of organizational solution much like microservices to separate concerns. This is important when collaborating with a large amount of people. Clear boundaries and all that. You pay for those boundaries with a convoluted mess of classes that describe the design pattern rather than the business logic. You end up with Ab…
"You pay for those boundaries with a convoluted mess of classes that describe the design pattern rather than the business logic. You end up with AbstractRequestInterfaceFactory type stuff." I disagree. If a design (call it an architecture) is clean and coherent, it's obvious. Because obviously a client must send the order to a server, which is protected by a gateway. And of course that gatway validates the client req…
what happens when the business rule clashes with the database's constraint implementation, because different people either misinterpreted, or due to incompetence or miscommunication?
I think splitting up sounds great in theory, but in practise, has lots of pitfalls. That's not to say it's not a good idea, but one musn't look at it with rose-tinted glasses.