Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 3 years ago.
Improve this question
I have a question about some terminology that's been confusing me for ages and I just can't seem to figure it out. Wikipedia tends to explain these things very formally which is very hard for me to understand...
The terms I've been struggling to understand are: problem domain, conceptual model, domain model, business model, business domain, business logic, domain logic etc. Some of them mean the same thing, some of them are used interchangeably, some of them mean different things in different contexts. What I'm asking for is a high level overview so I don't get confused about these terms...
Are these terms all part of domain driven design? Is it OO speak? In what context should I place them?
This is what I understand so far:
A domain is the subject matter (i.e. the world that you're modelling), and a model tries to explain a concept/subject concisely.
Thus a domain model (=conceptual model) tries to explain the domain concisely.
Thus a business model would explain what a business does, and therefore a business would be the same as a domain, except that a domain is broader, it's not just limited to a business.
I have some experience in ER modelling, and I understand from wikipedia that an ER model is one of many techniques that is used to represent the conceptual model (domain model).
I might be totally wrong, but it should show you where my confusion is...
I doubt there's one comprehensive, formal definition of these terms, but in my experience the following are generally accepted definitions:
A Domain is an area of concern, or as you say, the subject matter. If the area of concern is a business, this would be a Business Domain. The term Problem Domain is more general.
A Conceptual Model is an abstraction of the concepts and relationships in a Domain: I'd agree that the terms Domain Model and Conceptual Model are largely interchangeable. The only difference is that the term Conceptual Model emphasises the fact that this is a model of the concepts, and doesn't reflect a software design.
The terms Business Logic and Domain Logic tend to refer to the rules that define the correct behaviour of the entities within the Domain. It might be possible to capture some of these rules in the Domain Model, for example though constraints on relationships or by using state charts. Whether you consider the Domain Logic to be a necessary part of the Domain Model probably depends on how formal your modelling needs to be, and the Domain in question.
Related
Apologies in advance if this question has already been answered, but I haven't been able to find a definition for what model actually means in this context that I actually grok.
I've heard the term model be used to describe just the persistence layer, all domain specific code, or just domain entities. From what I've read, anemic domain models seem to be regarded as a bad thing, but the specific reasons as to why don't quite seem to click with me and I think it's because I don't know what model is referring to in this context. US this specific to MVC?
If it's just referring to entities, what is the issue with only putting the logic to keep data integrity in the entities and the putting the logic for actually utilizing those entities into service classes? Is that still considered anemic? If that is the case how can you actually implement rich domain models without breaking single responsibility principle.
The answer doesn't need to be framework or language specific, but if it matters I'm working with php and Symfony2.
Thanks in advance anybody who takes the time to provide me some clarity!
Just on the distinction of what should be in the service layer versus the domain layer, here's a nice article by Martin Fowler on Anaemic Domain Models.
The anti-pattern he talks about is when the domain model lacks the domain logic & is really just a collection of getters & setters.
The fundamental horror of this anti-pattern is that it's so contrary
to the basic idea of object-oriented design; which is to combine data
and process together. The anemic domain model is really just a
procedural style design.
Quoting Eric Evans, he says:
Application Layer [his name for Service Layer]: Defines the jobs the
software is supposed to do and directs the expressive domain objects
to work out problems.
…
Domain Layer (or Model Layer): Responsible for representing concepts
of the business, information about the business situation, and
business rules. State that reflects the business situation is
controlled and used here, even though the technical details of storing
it are delegated to the infrastructure. This layer is the heart of
business software.
[My emphasis]
Generally, his blog posts are a great introduction to some of the concepts within DDD.
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 6 years ago.
Improve this question
Hi guys let's say I have a new project an inventory system. I will be using Java. I go to my client gather some requirements and after I gather them I will model those requirements. Which should I do first? my class diagrams/domain models? or data model? and why? i would really like you opinion on this. what do you do in the real world in software development?
im using these techs: Java, Hibernate(ORM), Scrum(methodology), postgresql(database)
Don't do either one first. Create a domain (object) model and an ER model in parallel. They should be very similar except that the domain model is concerned with data and behavior while the ER model is concerned only with data.
However you need to be very careful to avoid a pitfall that many practitioners, even experts ones, fall into. That is the confusion between analysis and design. Both your domain model and your ER model should be analysis models and not design models. That means that they describe the problem and the requirements, and not the features you are going to add when you design the solution.
In particular, many of the ER diagrams you see in this forum are really relational data models, even though they use ER notation. And they incorporate design features like foreign keys and don't limit themselves to features that are inherent in the information requirements.
Failure to pin down the requirements fairly precisely before design begins is a major source of failure in large scale projects. In small scale projects, not so much.
My 2 cents...
Data tends to be longer-lived, more stable and ultimately more important than code. So your approach should be data-centric. If you structure and normalize your data properly (and ER diagram is important tool for doing that), the rest will naturally follow.
IMO you should definitely not start thinking about your Data Model first.
The reason is that it's up to your Domain Layer to address all business needs.
Your Domain Layer must be agnostic. It should not be tied to any specific technical implementation nor reference any kind of framework. It should be self contained and work alone. When designing your Domain Layer, do not think about persistence or even the way your data will be displayed. If you need methods to store your data, or methods to gather information from specific UI container like Session, just use Interfaces.
When designing a Data Model, you're tied to the RDBMS you're going to use to store your data. You will think about the way your schema will be structured to store and access data efficiently. But the thing is that the Business doesn't care about how good your queries will perform.
It's always a good thing to defer critical decisions like the UI, frameworks, database and so on, when you can. That way you focus only on business needs.
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 5 years ago.
Improve this question
As we know UML contains 13 types of diagrams (structural and behavioral)
before starting a software developement, we are in requirement and design phase so which diagram should be create and when? .. What should be the sequence of diagrams creation in UML in requirement and design phase?
In fact if there is no rigid sequence then first we need to create structural diagram rigidly but the behaviour like Activity diagram may change according to user experience?
Can we create a deployment diagram and component diagram as one only?
There's absoultely no rule regarding the sequence of such diagrams.
Sometimes, when the structure of the data and the behavior of your domain model is easily defined or well documented, creating the class diagrams first allow for clearer abstractions that aid in creating a sequence diagram that makes sense.
In other cases, when the nature of the domain model is unknown or unclear, it will make more sense to create a sequence diagram first, and then glean classes from that.
What I am sure of is that revisions of these diagrams will become concurrent with each other (e.g., sequence diagrams may reveal something that wasn't taken into account for in the class diagrams, and vice versa).
Likewise, after starting software development these diagrams may change yet again, as more intuitive, or more maintainable abstractions and designs reveal themselves whether via unit tests or user-experience testing and so on and so forth.
Never get enamoured with the idea that these diagrams are rigid in any way and thus requires a sequence in creation -- trust me, they won't be. If you treat them as rigid and infallible, you're shooting yourself in the foot AND tying one arm behind you in your software development effort.
UPDATE As reflected in the comments, if you're really lost as to what diagram to go first with, the Use Case Diagram would be very important as early as the requirements gathering phase.
Beyond that, what I wrote above applies.
I agree with Jon and Pete, but respectfully add that UML is the what and the how varies.
There are processes like OOA and OOD (OOAD) which describe the how and what is UML. The wiki articles helpful, but it works more like this. Many RUP processes developed also involve the how of UML.
A standard set of orders for a user involved project (again use what you need):
1. Use Case (Focused on User/System Interaction.
2. Activity/Sequence that drills into the Use Cases.
3. Component/Interface diagram if you are connecting systems.
4. Package/Class if you are doing a large OO build.
5. Deployment to show what goes where in the infrastructure.
Nothing magical about the model/diagram elements I listed above but this seems to be the common set.
In fact if there is no rigid sequence then first we need to create structural diagram rigidly but the behaviour like Activity diagram may change according to user experience?
Form follows function. If you need to change the behaviour, there's a good chance you need to change the structure from which that behaviour emerges.
Usecase analysis is an effective way to capture the goals from the requirements. Use the usecase descriptions to identify your domain objects and produce a domain model. I find CRC useful at this stage even though it not official UML. Once I have produced my domain model I produce a Sequence Diagram for each usecase. Though Activity diagrams are also a useful alternative. I resolved the Domain model into a more detail class model. At this stage it is straightforward to produce a deployment model.
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 have heard umpteen times that we 'should not mix business logic with other code' or statements like that. I think every single code I write (processing steps I mean) consists of logic that is related to the business requirements..
Can anyone tell me what exactly consists of business logic? How can it be distinguished from other code? Is there some simple test to determine what is business logic and what is not?
Simply define what you are doing in plain English. When you are saying things businesswise, like "make those suffer", "steal that money", "destroy this portion of earth" you are talking about business layer. To make it clear, things that get you excited go here.
When you are saying "show this here", "do not show that", "make it more beautiful" you are talking about the presentation layer. These are the things that get your designers excited.
When you are saying things like "save this", "get this from database", "update", "delete", etc. you are talking about the data layer. These are the things that tell you what to keep forever at all costs.
It's probably easier to start by saying what isn't business logic. Database or disk access isn't business logic. UI isn't business logic. Network communications aren't business logic.
To me, business logic is the rules that describe how a business operates, not how a software architecture operates. Business logic also has a tendency to change. For example, it may be a business requirement that every customer has a single credit card associated with their account. This requirement may change so that customers can have several credit cards. In theory, this should just be a change to the business logic and other parts of your software will not be affected.
So that's theory. In the real world (as you've found) the business logic tends to spread throughout the software. In the example above, you'll probably need to add another table to your database to hold the extra credit card data. You'll certainly need to change the UI.
The purists say that business logic should always be completely separate and so would even be against having tables named "Customers" or "Accounts" in the database.
Taken to its extreme you'd end up with an incredibly generic, impossible to maintain system.
There's definitely a strong argument in favour of keeping most of your business logic together rather than smearing it throughout the system, but (as with most theories) you need to be pragmatic in the real world.
To simplify things to a single line...
Business Logic would be code that doesn't depend on/won't change with a specific UI/implementation detail..
It is a code-representation of the rules, processes, etc. that are defined by/reflect the business being modelled.
I think you confusing business logic with your application requirements. It's not the same thing. When someone explains the logic of his/her business it is something like:
"When a user buys an item he has to provide delivery information. The information is validated with x y z rules. After that he will receive an invoice and earn points, that gives x% in discounts for the y offers" (sorry for the bad example)
When you implement this business rules you'll have to think in secondary requirements, like how the information is presented, how it will be stored in a persistent way, the communication with application servers, how the user will receive the invoice and so on. All this requirements are not part of business logic and should be decoupled from it. This way, when the business rules change you will adapt your code with less effort. Thats a fact.
Sometimes the presentation replicates some of the business logic, mostly in validating user input. But it has to be also present in the business logic layer. In other situations, is necessary to move some business logic to the Database, for performance issues. This is discussed by Martin Fowler here.
I dont like the BLL+DAL names of the layers, they are more confusing than clarifying.
Call it DataServices and DataPersistence. This will make it easier.
Services manipulate, persistence tier CRUDs (Create, Read, Update, Delete)
For me, " business logic " makes up all the entities that represent data applicable to the problem domain, as well as the logic that decides on "what do do with the data"..
So it should really consist of "data transport" (not access) and "data manipulation".. Actually data access (stuff hitting the DB) should be in a different layer, as should presentation code.
If it contains anything about things like form, button, etc.. it's not a business logic, it's presentation layer. If it contains persistence to file or database, it's DAL. Anything in between is business logic. In reality, anything non-UI sometimes gets called "business logic," but it should be something that concerns the problem domain, not house keeping.
Business logic is pure abstraction, it exists independent of the materialization/visualization of the data in front of your user, and independent of the persistence of the underlying data.
For example, in Tax Preparation software, one responsibility of the business logic classes would computation of tax owed. They would not be responsible for displaying reports or saving and retrieving a tax return.
#Lars, "services" implies a certain architecture.
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 4 years ago.
Improve this question
An answer to a Stack Overflow question stated that a particular framework violated a plain and simple OOP rule: Single Responsibility Principle (SRP).
Is the Single Responsibility Principle really a rule of OOP?
My understanding of the definition of Object Orientated Programming is "a paradigm where objects and their behaviour are used to create software". This includes the following techniques: Encapsulation, Polymorphism & Inheritance.
Now don't get me wrong - I believe SRP to be the key to most good OO designs, but I feel there are cases where this principle can and should be broken (just like database normalization rules). I aggressively push the benefits of SRP, and the great majority of my code follows this principle.
But, is it a rule, and thus implies that it shouldn't be broken?
Very few rules, if any, in software development are without exception. Some people think there are no place for goto but they're wrong.
As far as OOP goes, there isn't a single definition of object-orientedness so depending on who you ask you'll get a different set of hard and soft principles, patterns, and practices.
The classic idea of OOP is that messages are sent to otherwise opaque objects and the objects interpret the message with knowledge of their own innards and then perform a function of some sort.
SRP is a software engineering principle that can apply to the role of a class, or a function, or a module. It contributes to the cohesion of something so that it behaves well put together without unrelated bits hanging off of it or having multiple roles that intertwine and complicate things.
Even with just one responsibilty, that can still range from a single function to a group of loosely related functions that are part of a common theme. As long as you're avoiding jury-rigging an element to take the responsibilty of something it wasn't primarily designed for or doing some other ad-hoc thing that dilute the simplicity of an object, then violate whatever principle you want.
But I find that it's easier to get SRP correct then to do something more elaborate that is just as robust.
None of these rules are laws. They are more guidelines and best practices. There are times when it doesn't make sense to follow "the rules" and you need to do what is best for your situation.
Don't be afraid to do what you think is right. You might actually come up with newer and better rules.
To quote Captain Barbossa:
"..And secondly, you must be a pirate for the pirate's code to apply and you're not.
And thirdly, the code is more what you'd call "guidelines" than actual rules...."
To quote Jack Sparrow & Gibbs.
"I thought you were supposed to keep to the code."
Mr. Gibbs: "We figured they were more actual guidelines. "
So clearly Pirates understand this pretty well.
The "rules" could be understood via the patterns movement as "Forces"
So there is a force trying to make the class have a single responsibility. (cohesion)
But there is also a force trying to keep the coupling to other classes down.
As with all design ( not just code) the answer is that it depends.
Ahh, I guess this pertains to an answer I gave. :)
As with most rules and laws, there are underlying motives by which these rules are relevant -- if the underlying motive is not present or applicable to your case, then you are free to bend/break the rules according to your own needs.
That being said, SRP is not a rule of OOP per se, but are considered best practices to create OOP applications that are both easily extensible and unit-testable.
Both are characteristics that I consider as of utmost importance in enterprise application development, where maintenance of existing applications occupies more time than new development does.
As many of the other posters have said, all rules are made to be broken.
That being said, I do think that SRP is one of the more important rules for writing good code. It's not specific to Object Oriented programming, but the "encapsulation" part of OOP is very hard to do right if the class does not have a single responsibility.
After all, how do you correctly and simply encapsulate a class with multiple responsibilities? Usually the answer is multiple interfaces and in many languages that can help quite a bit, but it's still confusing to the users of your class that it may apply in completely different ways in different situations.
SRP is just another expression of ISP :-) .
And the "P" means "principle" , not "rule" :D