DDD questions

check this thread, it might answer some of your questions: https://laracasts.com/discuss/channels/requests/domain-driven-design

@Ruffles - Thank you, I will leave it opened, maybe other folks can have more to add.

Thanks for linking to that @Ruffles. I'll also try and define some of the terms explicitly asked by @yayuj

Before I can answer them, I'll ask two three more questions:

What is the domain? I went into this a bit in that post, but the domain is just a term that describes thing you're making software for - the problem you're trying to solve. It could be building a forum, a car dealership inventory system, or an accounting program. It has unique requirements and rules.

What isn't the domain? The domain isn't stuff like database storage, sessions, cookies, routes, middleware etc. That's all infrastructure or application logic. It's used to help make the site function, but it is separate from all of the logic used to implement the domain model.

What is the domain model? The domain model is a conceptual representation of the domain. Just like a clay or digital model of a concept car - it helps designers and engineers visualize what they're building, and find holes/problems with it at the model level, before they discover their mistake after building 10,000 of them! In terms of software, the model is usually nothing more than lots of diagrams illustrating how the software needs to behave, to properly satisfy the requirements of the domain.

What is domain logic? Domain logic is merely the code used to implement the domain model. E.g. for a forum, the code needed for banning a user, posting a topic, editing a topic, allowing members to edit their own topics, but not other peoples' topics etc. Again, this is different from things like the database code (or Eloquent) or anything. It might use Eloquent, but Eloquent is doing all of the nitty gritty work of writing the SQL queries etc. Your domain doesn't care about those details. Nor does it necessarily care that your input is coming through HTTP. Which leads me to the domain layer.

What is domain layer? Basically the same thing as domain logic - just another way of describing it. In a perfect world, software is built as layers, stacked on top of one another, with very discrete edges and well defined integration points. "Infrastructure" (database access, sessions, cookies, etc) might be one layer. "Application" (router, controllers, middleware stack, views) might be another layer. Note that these are relatively generic, and this is what Laravel gives you so that you don't have to think or worry about it too much. "Domain" is the layer that encapsulates the actual thing you're building, using Laravel (or any other framework) as a tool.

The "in-a-perfect-world" key is to build your domain layer with as little dependence on the infrastructure and application layers as possible. Easier said than done, of course.

What is a domain object? Merely an object that represents a core element of your domain logic. A User, a Subscriber, a Member, a Forum etc. Usually these are entities - that is an object with a persistent identity. They can also be value objects that don't necessarily have a unique identity, just encapsulate some properties and logic for the purposes of code re-use. A Command is a value object, for instance. EnrollmentPeriod could be another value object (used to describe dates when a user might be able to enroll in classes). But here's something to throw you for a loop, EnrollmentPeriod might also be an entity, if you persist it and identify it by its id. Conversely, it would only be a value object if the thing that defined it was the enrollment start date, and enrollment end date - changing one of these changes its identity. It really depends on how you use it.

A domain object could also be a plain old class (service class, helper class, whatever you want to call it), not really a quick "one and done" value object like a Command, but also not something you would persist in the database with an identity, either.

In short, a domain object is basically anything that lives in your domain layer to help implement the domain model.

What is a domain event? A domain event is simply a reaction to something that happens in your domain layer/logic. Going back to the forum example, if a user submits a new topic, you'll want to broadcast an event doing so. Why? Several other domain/business rules might care about it:

• When a user submits a new topic, send an email to all subscribers in for that forum category
• When a user submits a new topic, send an email to all friends/followers of that user
• When a user submits a new topic (to a moderated forum), send a message to a moderator to review and approve the topic

So by broadcasting one event describing the act of posting a topic, several other responses to that event can occur, without needing to touch the code that posts the topic.

What is a domain expert? The person who understands their domain - their problem. For example, say you were building air traffic control software - the domain expert would be the aircraft controller who tells you how air traffic controlling (the domain), works, and what he needs the software to help him do. Sometimes your client is not really an expert in their own domain, and you need to identify the problem for them. They might not have really gotten to the heart of the problem, or the heart of the thing they want.

What is business logic, business layer? To be honest, I don't have a good answer. One might argue that business logic is merely a subset of the domain, but still lives inside of the domain layer. Things like "If user purchases 10 items, give $50 credit". That's a business rule that you would write code to satisfy. But personally, I think "business" and "domain" are mostly interchangeable in this concext, don't worry about differentiating them, as if there is a difference, it's likely going to be splitting hairs in most applications.

What is the core domain? Fluff term, just another term for the domain.

Seriously guys, that is why I love being here. If I was a girl I'd kiss you all. (haha) - Thanks.

@tag - Excellent reply. Nice job.

@tag - One of the most well described reply I've ever read. I liked that in your other reply you gave an example of a real life situation and your terms explanation was really elaborated. Great.

Great @tag, thanks for sharing with us.

@tag that is a brilliant write-up! Thanks for sharing.

@yayuj https://groups.google.com/forum/#!forum/dddinphp this is one of the good places to learn more about DDD. Maintained by Mathias Verraes

@Ruffles - Thank you very much.

@tag That is excellent!!

@tag I want to buy you beer :-D

@tag Damn... best answer I've seen on here! Good job.

take a look in this oversimplification. https://github.com/davists/Lumen-Doctrine-DDD-Example