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 as Course, Student, CourseRegisteration then starts to become harder to maintain business rules. For example if you wanted the RegisterForCourse method to limit student course registration to 10, it would now have perform another query.

If start doing queries that don't match up your domain model, then should probably do CQRS. Which would allow you to build a model optimized for queries.

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.

"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.

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.

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.

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.

"Most companies don't find it economically justifiable to re-write based on slightly different customer requirements and most companies have many deployments,"

Then don't. Make the domain model customisable with various options.

Having specific methods for specific companies seems a lot worse.

I build SAAS applications which have various customization options customers can do. I don't really have a problem with it. I've designed a clean way to customise.

I do more enterprisey stuff so our customers are a little less accepting of model restriction. I find a service based architecture more flexible as its pretty easy swap out services that just work off a common currency that define different or customisable behaviour. The sort of situation where an entity is performing business logic makes that harder do as opposed to swapping out the service.

I made the same mistakes as OP and learnt the hard way. I encourage you to explore a greater purity in your models in the future because I genuinely believe it leads to better code.