Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 days ago.
Improve this question
I've been reading Eric Evan's DDD book and I got a bit confused. Maybe I'm too pedant, but I want clarity in things I deem important.
Eric states that when doing DDD we should first create a model. And based on the model we should create the design. Why? Shouldn't the design come first and then the model? Since first we have to design something "make a plan, or a drawing or diagrams", then model it "maybe add more diagrams or software artifacts with more details" that eventually we will implement in code.
What am I missing?
I've been investigating the words lately to understand precisely what they mean, because I understood that I devised some incorrect conclusions or even misinterpreted some terms, which is quite dangerous.
In my understanding in the real world. Design comes first and then comes the model. Even reading the definitions on google translate / wikipedia or other articles kind of confirm this. First we plan something "design", and then we model it, "add details to the design or give shape the design".
It will probably be useful to review the introduction to section I.
A model is a selectively simplified and consciously structured form of knowledge. An appropriate model makes sense of information and focuses on a problem.
A domain model is not a particular diagram, it is the idea that the diagram intends to convey. It is not just the knowledge in the domain experts head, it is a rigorously organized and selective abstraction of that knowledge. -- Evans, 2003
Another useful lens might be Technical Debt, as described by Ward Cunningham
if we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were gonna continually stumble over that disagreement and that would slow us down which was like paying interest on a loan.
The "proper way to think about our financial objects" is the model; the gap that "would slow us down" is the disagreement between the model and the design of the program.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am coming from the Embedded Systems domain with more than 3 years experience.
In my current project, at the beginning, I was only responsible for only software development and the Team consisted of 3 people.
But, as time passes, hardware eng. and project lead eng. left the job respectively. So far, the project moved with a zero- architecture documentation to give an output as fast as possible. Later, new project lead took over the project and started from the begining with applying V-model. We started to create product specs->HLR->DLR on EXCEL. But now, He left the job too :). Now, I am alone on my way with nearly 700 pieces of well written product requirements. Anyway, I started to gathering and classfying requirements as non-functional, functional, business, stakeholder etc. As gathering non-functionals, I also classified them scalability, performance, regulatory, design contrains etc. So far, I did not draw any use-case. Please verify me here, what I know is that input of use-case are functional requirements. So, I created a use-case cards and now I am planning to write use-case cards for each functional requirements then also write a sequence diagram for each use-case card. Now till here, am I going right ? Does notations used in use-case such as include, extend etc. help me to create class diagram ? Is this also right way ?
Can classes be derived from use-cases?
When Ivar Jacobson invented use-cases he aimed at a development method that would be driven by the use-cases and allow to methodically derive the implementation from the use cases. That was his vision end of the 80s. His first attempt was called Objectory, which was bought by a larger company and lead to Rational Unified Process, which was generalized to be less proprietary into the Unified Software Development Process (Unified Process, or UP in short).
There is in particular one practice that allows to translate a use-case into classes: the Entity Control Boundary approach: use-cases become «control» classes, links between use-cases and actors become «boundary» classes, and «entity» classes are created for the business objects identified in (or derived from) the use-case narratives.
Once these first candidate classes are modelled, further work is undertaken during the design and classes may get reorganized to best fit into the solution (e.g. several boundary classes are regrouped for designing the GUI, and may thereafter be decomposed into UI elements, etc...).
But is this the best approach in your case?
UP is iterative and incremental, and fits well into modern version of the V-model, since the early iterations of the elaboration phase aim to stabilize the architecture and teh components (or sub-systems).
However, this may be a very time-consuming approach, especially considering the huge number of use-cases that you have. If you look at all the questions that modelling a use-case usually raises, especially if you add «include» and «extend», you risk to spend a lot of time (more than 300 days?) to draw robust use-case diagrams. And then, using ECB, your requirements might be outdated before you finish the design!
Alternatives
On the other side, some non-academic authors claim that every system has 3 to 5 really main use-cases: as a user I don't have 700 goals for using a system. So you'd better identify these and see how they relate. It's probable that many of the other requirements are far too detailed and could easily be assigned as additional information for the main use-cases.
In a similar thought, Ivar Jacobson has adapted his method to the current software engineering reality, with the use-case 2.0 approach. Don't misunderstand me, the UML would still be the same, but ECB no longer appears (modern frameworks influence much more the design of the boundaries than the use-case model, and entities are modelled using more focused approaches, such as DDD).
The idea behind use-case 2.0 is to slice the main use-cases into several smaller parts and start to develop something that makes sense for the user and can then be further refined.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
In Eric Evans book on domain driven design it is written:
Domain modeling is not a matter of making as “realistic” a model as
possible. Even in a domain of tangible real-world things, our model is
an artificial creation. Nor is it just the construction of a software
mechanism that gives the necessary results.
Now I have two questions:
Should a model be designed
somehow that it could evolve to a more
realistic shape whenever NEEDED
without touching the core model in previous iteration?
If the answer to the previous question is positive, where can I learn how to create realistic core models?
Again if the answer to the question one is possible, would a day come that our model reflects any problem in the world?
Domain Model should not reflect real world.
It should only show one point of view depending on the context.
Let's say we got a glass.
One may think, well it's a glass and we can fill it with water. It is used to drink.
Other may think, well it's a product and we can sell it.
Another one may say, glass an inventory item. I don't care how does it looks like, but how many glasses I got here.
Depending on the context, we model glass differently. Still it is the same glass, but means something else.
All information related to the subject you can find on Udi Dahan's blog.
And more in the subject of modeling reallity, can be found here Don’t try to model the real world, it doesn’t exist.
Should a model be designed somehow that it could evolve to a more realistic shape whenever NEEDED without touching the core model in
previous iteration?
No, a model should reflect the particular problem under consideration. If the underlying problem changes, the model should reflect it. Let's say your modeling a hotel reservation system, a warehouse system, or a store point-of-sale system, your model should be a representation of the current concepts in those domains and the interaction between them. Models are not versioned over time.
2 and 3
No.
In a problem domain, there are obvious things and hidden things.
If you just model the obvious, apparent notions (whether real world objects or intangible concepts), creating a class for each one, you will have a realistic model but it will miss the point. It won't be a deep, insightful domain model.
To go beyond mere realism, you should sit with a domain expert and try to discover the hidden things in the problem space that will be helpful to the solution space - your application.
For instance, talking to a railway traffic expert, you might uncover heuristics or properties in the way train departures and arrivals are orchestrated that even the expert didn't realize or put a name on before. Naming these things will allow you to reason about them and ultimately act on them in your application. Or, you might have an elephant in the room - a big, widely used historical concept - and decide to reject it from your ubiquitous language because it doesn't describe a subpart of the problem accurately enough.
Realistic here is meant as opposed to refined, rationalized, not to totally made-up.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
How to model logic of complex operations? For example save methods for root entities where state, versions and various atributes should be handled according to some logic. DTOs and entities exist.
I was thinking about sequence diagram, activity diagram, natural language and some abstract code.
I think sequence diagram is not appropriate because it's more likely for modeling of an interaction.
Activity diagram seems to me too clumsy and I don't know where to put instructions like assignments of attributes. It doesn't look right in a note or description of an activity.
Natural language is ambiguous and there is little information in large volume.
Mayby abstract code could be the right choice. Or its combination with natural language. Is there any recommended form? I don't want to write Java code.
If you mean - complex algorithms, they are probably best modelled by activity diagrams. Since UML 2.0 they have actions for practically all kind of operations (including assignements). That's not the problem.
I agree though that in some cases it would maybe better to use some more informal approach. Activity diagrams are very slow to draw and to layout and the added value is questionable (if no automation is used later on). Regarding the statement that they are "clumsy" - you can always overcome this problem by a nice structuring and hierarchical breaking your model in several levels (as single activities can contain whole diagram inside them).
Maybe a mix would do the work - outline the main steps of the algorithm, maybe main decisions, loops, invocations, whatever is importang for you. Later add detailed description of those single activitis: using pseudo-code, natural language or even another embedded diagram (states, activities).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Looking for a bit of a steer on "how things are done" with regards to defining requirements for a software based project.
I'm fully up to speed with what goes into a requirements catalogue and how useful UML modelling can be.
My question, how are the two linked? Should you write out requirements into the catalogue for any requirements you model using UML - essentially duplicating requirements?
For example,
- A user wishes to source a "product" from a supplier
- To do this they will enter their product details into a "breifing" form
- In this scenario I'd look to use a class diagram to list out all the "briefing" fields (shown on the briefing form) against a "product" class
But, how do I tie those requirements back to the requirements catalogue? If they're not referenced there how will a developer know those requirements exist?
Any help greatly appreciated!
Thanks,
Dan
You should use an Use Cases diagram to make the bridge between requirements and UML.
You could then explicit relationships between your classes and each use case.
A developer can see a particular class is linked to one or many use cases (requirement).
Some modeling tools allo wto include requirements into your UML model. Then you have an explicit link.
For example: http://www.sparxsystems.com.au/downloads/whitepapers/Requirements_Management_in_Enterprise_Architect.pdf (see p. 16)
Otherwise you may export your diagrams and include them into your catalogue document.
Forming the requirements catalogue and having elicited and analysed your audiences requirements up to the point of formal signoff, based on the needs of a project you UML diagrams would normally make reference to a working of functionality or a process which you captured, process workflows/activity diagrams are sound for stakeholders to visualise how there internal processes work, use cases, class diagrams, sequence diagrams etc are more useful for development and QA teams during the design/development phases for devs and qa's.
For each requirement just make reference to the UML diagrams through the use of the requirements ID. But as mentioned earlier, ensure you have traceability between requirements and UML and vice versa,
Hope this helps
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I keep seeing DDD (Domain Driven Design) being used a lot in articles - I have read the Wikipedia entry about DDD but still can't figure out what it actually is and how I would go about implementing it in creating my sites?
Firstly, if you don't know that you need it then it's possible that you don't need it. If you don't recognize the problems that DDD solves then maybe you don't have those problems. Even DDD advocates will frequently point out that DDD is only intended for large (>6 month) projects.
Assuming that you're still reading at this point, my take on DDD is this:
DDD is about trying to make your software a model of a real-world system or process. In using DDD, you are meant to work closely with a domain expert who can explain how the real-world system works. For example, if you're developing a system that handles the placing of bets on horse races, your domain expert might be an experienced bookmaker.
Between yourself and the domain expert, you build a ubiquitous language (UL), which is basically a conceptual description of the system. The idea is that you should be able to write down what the system does in a way that the domain expert can read it and verify that it is correct. In our betting example, the ubiquitous language would include the definition of words such as 'race', 'bet', 'odds' and so on.
The concepts described by the UL will form the basis of your object-oriented design. DDD provides some clear guidance on how your objects should interact, and helps you divide your objects into the following categories:
Value objects, which represent a value that might have sub-parts (for example, a date may have a day, month and year)
Entities, which are objects with identity. For example, each Customer object has its own identity, so we know that two customers with the same name are not the same customer
Aggregate roots are objects that own other objects. This is a complex concept and works on the basis that there are some objects that don't make sense unless they have an owner. For example, an 'Order Line' object doesn't make sense without an 'Order' to belong to, so we say that the Order is the aggregate root, and Order Line objects can only be manipulated via methods in the Order object
DDD also recommends several patterns:
Repository, a pattern for persistence (saving and loading your data, typically to/from a database)
Factory, a pattern for object creation
Service, a pattern for creating objects that manipulate your main domain objects without being a part of the domain themselves
Now, at this point I have to say that if you haven't heard of any of these things before, you shouldn't be trying to use DDD on any project that you have a deadline for. Before attempting DDD, you should be familiar with design patterns and enterprise design patterns. Knowing these makes DDD a lot easier to grasp. And, as mentioned above, there is a free introduction to DDD available from InfoQ (where you can also find talks about DDD).
Take StackOverflow as an example. Instead of starting to design some web forms, you concentrate first on doing object-oriented modelling of the entities within your problem domain, for example Users, Questions, Answers, Votes, Comments etc. Since the design is driven by the details of the problem domain it is called domain-driven design.
You can read more in Eric Evans' book.