I am incredibly new to Domain Models and I am trying to build up my understanding. I have created this domain model around a scenario which I will provide. I feel this model is simple and as a result, feels incorrect and might be missing elements I might not have thought of although, I cannot think of what else might need to be included in a domain model given the scenario. The idea is to demonstrate the relationship between real world class entities which I feel I have managed to achieve.
Scenario: Management Application that allows you to create users, projects, companies and issue tickets. The projects are assigned to companies, the users are assigned to projects and the issue tickets are assigned to the users. Tickets have a status which can be changed.
Changes
Implementing proposed changes. I think this is a better way to represent the idea based on the feedback returned, especially in regards to the use of composition. I have also updated the multiplicities to better represent the scenario.
Further changes
The diagram should stay as simple as possible, but not more.
In this specific case:
The two specializations of User might be too complex for the need: a User stays a User, isn’t it? If you really need to take into account differences between categories of users, and especially if the category changes over time, you'd better consider (object) composition over inheritance (or better worded for UML: prefer association over inheritance).
The associations might be too simple or incomplete. For example, before an Issue ticket gets assigned to a User, isn’t it also associated to a Project or a Company? It is not clear either if User is also associated to Company (e.g. multi-tenant cloud scenario) or if there is no such association (e.g service provider scenario, where the company is in fact a customer company).
Some associations may hide association classes, e.g. do you expect to monitor how many time a user worked on a ticket?
It entirely depends on the purpose of your model.
Some models might be created to stimulate discussion and further discovery. Some might be required for the senior stakeholders to approve. Some might be for developers to work from. Others might be for marketing material.
Your model is ok for stimulating discussion and further discovery.
Related
Suppose I make a class diagram for a social network system such as facebook. Should the notifications and discussion messages have their own classes?
I do really think they should. I made a full class diagram for such a system, with notifications and messages as classes, but my teacher told me to exclude them. Now I am confused.
This is a very interesting question for three reasons.
1. What’s the scope?
This is a core question for any work that you’ll do in your developer career: what’s the scope of the system?
is it just core social networking functionality of one to many communication, like you had on Facebook in its early days?
or is it a full clone of facebook, including its messaging features, but also its advertising and moderating features?
If it’s the first, you’ve done too much. If it’s the second, you forgot important parts.
Rule 1: Whenever there is a doubt about the scope, clarify it with your coach/manager/stakeholder before thinking you know what there is to do.
This will avoid you the frustration of doing work that is not valued. It will avoid your future customers the frustration of not getting what they’ve expected, or paying too much for something they didn’t ask for.
2. What’s the approach?
Whenever you model some software, there’s a purpose. Class diagrams can be used for different purposes. For example:
is it for analyzing the requirements? In this domain, you will certainly have a class for Post, Comment and UserAccounts as well as associations between them. But you’d limit yourself to the “problem space” and not address the software solution and its UI.
is for the design of the system? then it probably should address how the system will work, and give some more details about how the UI will interact with the domain object. This kind of diagram might be more detailed and show the “solution space”.
Rule 2: if asked to do some modeling, always clarify the purpose. In the real world, if not asked explicitly to model, clarify the agreed approach within your team.
3. Always clarify with the person the closest to the source
(the subtitle is already the rule).
Now, is the notification a part of the UI, because they shows posts that changed and it’s part of the solution design? Or is it part of the domain, because the need for notification is independently of the chosen software solution? And because moreover notifications need to be tracked and delivered, and the they will work differently on mobile apps (push) and on web pages (pull)? As you see there is some room for interpretation, and depending on his/her arguments, the teacher is not necessarily wrong.
Conclusion
As you see, it’s not right or wrong: there are a lot of nuances between the two. There are plenty of reasons that could justify your teacher’s position. I see at least two other unrelated ones:
to adapt the time of the exercise to the average capability of your class (which would be a good sign for you)
because the teacher already know the next questions and he/she already know that notifications will make it much more difficult (which would show that the teacher was nice).
My advice: trust your teacher, and in any case engage a discussion to understand the arguments, before jumping to quickly on unproven conclusions.
Key takeaway: requirement analysis and modelling are a communication activity more than a technical activity. Whenever there’s a doubt, engage discussion with your stakeholders before seeking advice from strangers on the net ;-)
What I'm trying to achieve is to develop an application implementing the DDD approach.
The story might sound silly but it's an actual, real life problem. Believe me.
The business looks as follows:
Let's say a company specializes in manufacturing sweets which are distributed to its own shops for sale.
The craftsman makes different types of candy depending on what is - and what is not - currently at the display at one of the company's shop.
When a basket of one flavour 'disappears' the seller replaces this type of sweet with a different kind from the shops storage cabinet.
Duplicates of flavours at the display shouldn't exist and the display should be populated with as much as the capacity allows or how much the manafacturer can handle to produce.
The sweets are distributed from the manufacturer's lab's storage to the shop's one depending on the demand.
Let's assume each worker has public view access to the display and the storage cabinet. Each worker (user) decides on it's own what to provide. The shops display view will be publicly accessible through the application to a potential client as an information what is currently on sale.
So far I have split the business logic into three separate (sub?)domains which are:
Production
Distribution
Sale
And of course each entity like Sweets, Storage, Craftsman, it's Repository etc. are placed respectively in their domain.
The concerns I approach are:
Is it appropriate that an entity (Sweet) is being passed from one domain to another?
Should a Provider be able to reach the StorageCabinet of one domain and pass it's content to another?
Is my reasoning proper? Correct me if I'm wrong or violating any DDD rules.
Thanks in advance.
The story might sound silly but it's an actual, real life problem.
This is great, actually. In his recent retrospective, one of the things that Greg Young called out is that "shopping cart" models are a really lousy as a teaching tool. He points out briefly that the interesting questions are in the supply chain.
Is it appropriate that an entity (Sweet) is being passed from one domain to another?
No, but a message (DTO) describing an entity's state might be passed from one domain to another.
You want to keep the flexibility to define the entities differently in each domain; that's part of the point of identifying bounded contexts.
Should a Provider be able to reach the StorageCabinet of one domain and pass it's content to another?
Probably not: your domain model isn't the book of record for the storage cabinet. Listen very carefully to Greg's comments on one way commands.
I have created a use case diagram for site similar to oDesk.
Site description: the place, where freelancers can find suitable jobs accordingly to their skills and pricing demands and where employers/clients can find suitable freelancers for their job postings with necessary skills and for stated price.
The goal of the site owner is: get income, by means of taking 10% fee from every payment made from employer/client to freelancer.
Have a look at the link below. Will be happy to hear any comments and advices!
I'm new here, but this question looks suitable for Business Analysts. This diagram does make sense. From my point of view, i would have added a "user" role (generalization of "employer" and "freelancer)". And aligned functions similar to "freelancer" and "employer" with "user" role.
From use full functionality point of view (it is what UseCase defines) your diagram is almost perfect. BUT, remove login usecase (it is not service..no body use system to login. Login is precondition for accessing security website functionality). Separate profile manage, block profile and other administration services (usecase) from the rest and build new diagram for them. There are mix of incompatible use cases at the same place.
Your "Make Payment" use case is off. You have it so that only the Employer doesn't make payments to anyone except possibly himself. Consider making the two types of payment into specializations of Make Payment (remove all the extends and includes except from the Make Payment to the Process Transaction), associating the Employer with the main use case, and associating the Site Owner and Freelancer each with the appropriate specialized use case.
Also, as Vladimir says, you might consider splitting this up into multiple diagrams.
So we may apply the domain driven design for multiple projects but there could be intersection of the same piece of domain model.
In this case, how to apply the domain driven design (use ORM, model first, generating database schema)? Create multiple databases with a lot of same tables? Or how to share data? Use synonyms? What is the possible strategy to resolve the sharing model (including data)?
Any suggestion is welcome. Thanks in advance!
In my previous project we had a lot of discussions regarding having redundant info in several models that have some shared parts.
What we found interesting is that we thought that several projects (not C# proj, but real large development projects) or call it systems very rarely share the exact same perspective on how using the model. We thought that in a larger domain that spans over several application/systems/projects you could spot several core's where you don't want the cores to be duplicated in each application.
It all ended up with a domain that where distributed on several machines. And we had GUID keys to bind them together in database. But since we did this "model first", sub domains looked at each other like infrastructure related services that where reached through Domain events.
Complicated? Not really. Here's an example:
Domain one (Salary review system) - We have a Salary Review statistic system which conduct evaluation on employees salary and how they related to their experience, age and performance. The Core is questionnaire form, work evaluation, questionnaire answers, rating. salary modification advices etc.
Domain two (Employee system) - Here you manage your employee, register new employees, handle rehab, maybe personal development, salary, employee contract, employee benefits etc.
Domain three (Performance management) - Here you handle history of employee experience, goals, achievements, and agreements between boss and employees about personal development, rating and grade of performance.
As you notice the Core of each domain is different but they share some concerns. Depending on deployment, infrastructure and requirement on how tight they should relate/respond to each other - the tech how to solve this could differ.
I Prefer to do this tech independent. We used NServiceBus for synchronizing domain through Domain Events (Udi Dahn's Domain Event Pattern).
For instance, Once we have completed a salary review for an employee and boss should be informed that Joe should get a chance of salary increase with 200 - 500 $ this year.
The method ApplySalaryReview on entity aggregate root Employee do not only save the review result, it also trigger domain event NotifySalaryReviewSubscribers which trigger an eventhandler HandleNotifySalaryReviewSubscribersEvent in Application layer that takes a infrastructure service in ctor. That service puts result in a message queue that all systems that need this info can subscribe on this message.
In our case, it is Domain two (Employee system). The employee system import result and notify employee's boss that he got new info for the upcoming salary talk with this particular employee.
I hope I may have shread some light on one way of doing it. There are so many other ways as well...
You might want to (re-)read the strategic design patterns in the blue book.
Can somebody please explain (in succinct terms) what exactly is domain driven design? I see the term quite a lot but really don't understand what it is or what it looks like. How does it differ from non-domain driven design?
Also, can somebody explain what a Domain Object is? How does domain differ from normal objects?
EDIT:
As this seem to be a top result on Google and my answer below is not, please refer to this much better answer:
https://stackoverflow.com/a/1222488/1240557
OLD ANSWER (not so complete :))
In order to create good software, you have to know what that software
is all about. You cannot create a banking software system unless you
have a good understanding of what banking is all about, one must
understand the domain of banking.
From: Domain Driven Design by Eric Evans.
This book does a pretty good job of describing DDD.
Register to download a summary of the book.
Domain Driven Design is a methodology and process prescription for the development of complex systems whose focus is mapping activities, tasks, events, and data within a problem domain into the technology artifacts of a solution domain.
The emphasis of Domain Driven Design is to understand the problem domain in order to create an abstract model of the problem domain which can then be implemented in a particular set of technologies. Domain Driven Design as a methodology provides guidelines for how this model development and technology development can result in a system that meets the needs of the people using it while also being robust in the face of change in the problem domain.
The process side of Domain Driven Design involves the collaboration between domain experts, people who know the problem domain, and the design/architecture experts, people who know the solution domain. The idea is to have a shared model with shared language so that as people from these two different domains with their two different perspectives discuss the solution they are actually discussing a shared knowledge base with shared concepts.
The lack of a shared problem domain understanding between the people who need a particular system and the people who are designing and implementing the system seems to be a core impediment to successful projects. Domain Driven Design is a methodology to address this impediment.
It is more than having an object model. The focus is really about the shared communication and improving collaboration so that the actual needs within the problem domain can be discovered and an appropriate solution created to meet those needs.
Domain-Driven Design: The Good and The Challenging provides a brief overview with this comment:
DDD helps discover the top-level architecture and inform about the
mechanics and dynamics of the domain that the software needs to
replicate. Concretely, it means that a well done DDD analysis
minimizes misunderstandings between domain experts and software
architects, and it reduces the subsequent number of expensive requests
for change. By splitting the domain complexity in smaller contexts,
DDD avoids forcing project architects to design a bloated object
model, which is where a lot of time is lost in working out
implementation details — in part because the number of entities to
deal with often grows beyond the size of conference-room white boards.
Also see this article Domain Driven Design for Services Architecture which provides a short example. The article provides the following thumbnail description of Domain Driven Design.
Domain Driven Design advocates modeling based on the reality of
business as relevant to our use cases. As it is now getting older and
hype level decreasing, many of us forget that the DDD approach really
helps in understanding the problem at hand and design software towards
the common understanding of the solution. When building applications,
DDD talks about problems as domains and subdomains. It describes
independent steps/areas of problems as bounded contexts, emphasizes a
common language to talk about these problems, and adds many technical
concepts, like entities, value objects and aggregate root rules to
support the implementation.
Martin Fowler has written a number of articles in which Domain Driven Design as a methodology is mentioned. For instance this article, BoundedContext, provides an overview of the bounded context concept from Domain Driven Development.
In those younger days we were advised to build a unified model of the
entire business, but DDD recognizes that we've learned that "total
unification of the domain model for a large system will not be
feasible or cost-effective" 1. So instead DDD divides up a large
system into Bounded Contexts, each of which can have a unified model -
essentially a way of structuring MultipleCanonicalModels.
You CAN ONLY understand Domain driven design by first comprehending what the following are:
What is a domain?
The field for which a system is built. Airport management, insurance sales, coffee shops, orbital flight, you name it.
It's not unusual for an application to span several different domains. For example, an online retail system might be working in the domains of shipping (picking appropriate ways to deliver, depending on items and destination), pricing (including promotions and user-specific pricing by, say, location), and recommendations (calculating related products by purchase history).
What is a model?
"A useful approximation to the problem at hand." -- Gerry Sussman
An Employee class is not a real employee. It models a real employee. We know that the model does not capture everything about real employees, and that's not the point of it. It's only meant to capture what we are interested in for the current context.
Different domains may be interested in different ways to model the same thing. For example, the salary department and the human resources department may model employees in different ways.
What is a domain model?
A model for a domain.
What is Domain-Driven Design (DDD)?
It is a development approach that deeply values the domain model and connects it to the implementation. DDD was coined and initially developed by Eric Evans.
Culled from here
Here is another good article that you may check out on Domain Driven Design. if your application is anything serious than college assignment. The basic premise is structure everything around your entities and have a strong domain model. Differentiate between services that provide infrastructure related things (like sending email, persisting data) and services that actually do things that are your core business requirments.
Hope that helps.
As in TDD & BDD you/ team focus the most on test and behavior of the system than code implementation.
Similar way when system analyst, product owner, development team and ofcourse the code - entities/ classes, variables, functions, user interfaces processes communicate using the same language, its called Domain Driven Design
DDD is a thought process. When modeling a design of software you need to keep business domain/process in the center of attention rather than data structures, data flows, technology, internal and external dependencies.
There are many approaches to model systerm using DDD
event sourcing (using events as a single source of truth)
relational databases
graph databases
using functional languages
Domain object:
In very naive words, an object which
has name based on business process/flow
has complete control on its internal state i.e exposes methods to manipulate state.
always fulfill all business invariants/business rules in context of its use.
follows single responsibility principle
DDD(domain driven design) is a useful concept for analyse of requirements of a project and handling the complexity of these requirements.Before that people were analysing these requirements with considering the relationships between classes and tables and in fact their design were based on database tables relationships it is not old but it has some problems:
In big projects with complex requirements it is not useful although this is a great way of design for small projects.
when you are dealing with none technical persons that they don,t have technical concept, this conflict may cause some huge problems in our project.
So DDD handle the first problem with considering the main project as a Domain and splitting each part of this project to small pieces which we are famous to Bounded Context and each of them do not have any influence on other pieces.
And the second problem has been solved with a ubiquitous language which is a common language between technical team members and Product owners which are not technical but have enough knowledge about their requirements
Generally the simple definition for Domain is the main project that makes money for the owners and other teams.
I do not want to repeat others' answers, so, in short I explain some common misunderstanding
Practical resource: PATTERNS, PRINCIPLES, AND PRACTICES OF DOMAIN-DRIVEN DESIGN by Scott Millett
It is a methodology for complicated business systems. It takes all the technical matters out when communicating with business experts
It provides an extensive understanding of (simplified and distilled model of) business across the whole dev team.
it keeps business model in sync with code model by using ubiquitous language (the language understood by the whole dev team, business experts, business analysts, ...), which is used for communication within the dev team or dev with other teams
It has nothing to do with Project Management. Although it can be perfectly used in project management methods like Agile.
You should avoid using it all across your project
DDD stresses the need to focus the most effort on the core subdomain. The core subdomain is the
area of your product that will be the difference between it being a success and it being a failure. It’s
the product’s unique selling point, the reason it is being built rather than bought.
Basically, it is because it takes too much time and effort. So, it is suggested to break down the whole domain into subdomain and just apply it in those with high business value. (ex not in generic subdomain like email, ...)
It is not object oriented programming. It is mostly problem solving approach and (sometimes) you do not need to use OO patterns (such as Gang of Four) in your domain models. Simply because it can not be understood by Business Experts (they do not know much about Factory, Decorator, ...). There are even some patterns in DDD (such as The Transaction Script, Table Module) which are not 100% in line with OO concepts.
I believe the following pdf will give you the bigger picture. Domain Driven Design by Eric Evans
NOTE: Think of a project you can work on, apply the little things you understood and see best practices. It will help you to grow your ability to the micro service architecture design approach too.
Get an organization wide understanding of the problem domain by
developing a ubiquitous language (a common mental model) per sub-problem-domain.
Use that language as close as possible in solution domains (code).
Only then choose technologies.
Don't be technology driven but problem domain or business driven.