Hot answers tagged domain-model
20
Most of the confusion seems to be around functionality that should not exist in the domain model at all:
Persistence should never be in the domain model. Never ever. That's the reason you rely on abstract types such as IRepository if part of the model ever needs to do something like retrieve a different part of the model, and use dependency injection or ...
8
The definition of 3-tier architecture is a special case of the n-tier architecture. In an n-tier architecture, there are n components and each one only interacts with the component immediately "above" and "below" it. A three-tier architecture has three such components.
Typically, a three-tier architecture consists of a user interaction layer, the business ...
7
so it would have been impossible to switch out to another ORM (not
that we wanted to)).
That seems wrong. A major advantage of the repository pattern is that you hide the data access logic and that it is easily exchangeable.
So far it feels as though I put my business logic in my domain model
and via repositories I would work with the ORM (which ...
6
How about
customer.SetDisabledBy(user);
or if using C# 4.0 or a different language with similar capabilities:
customer.SetDisabled(by: user);
or if you're using C# 3.5 or newer, you can write the following:
user.DisableCustomer(customer);
while having the DisableCustomer method be an extension method sitting in a class called CustomerActions which ...
6
It actually depends on the level of details in the class diagrams and the way they are used.
An important distinction that has to be made: a UML class is not (necessarily) the same as a programming language class. It denotes domain concepts that may be implemented in many different ways (or not at all).
Defining these concepts is a job for the domain ...
5
Your table design for handling hierarchical categories is correct. This is a general purpose design which can handle situations where there is no way to predict exactly how deep the tree will be along any one branch.
What you might want to consider in your design is whether you are going to make any amendments to assist you with the practicalities of ...
5
I think the general goal with ORMs is that the database is mapped directly to domain objects, which are ideally POCOs. So the answer to your question is yes. Now that EF is capable of mapping to POCOs it is ideal to consider those POCOs as domain entities. For other ORMs such as NHibernate this has been possible for awhile and I believe people have ...
5
You are intermixing
entities should not access the repositories
(which is a good suggestion)
and
the domain layer should not access the repositories
(which might be bad suggestion as long as your repositories are part of the domain layer, not the application layer). Actually, your examples show no case where an entity accesses a repository, ...
4
Domains which have entities where the number of attributes (properties, parameters) that can be used to describe them is potentially vast, but the number that will actually apply to a given entity is relatively modest.
An example of such a domain would be a medical practice, where there are a vast number of possible symptoms, but the number of symptoms that ...
4
Is it normal for a domain expert to do class diagrams?
If a domain expert does class diagrams in the traditional sense*, then the answer is "absolutely not". You should resist this as much as you can, for everyone's benefit.
I have been in a situation like that in a start-ups many years ago, where a very strong domain expert has been trying to map a ...
4
IMO this is a false dichotomy. If you follow SRP, you keep your system simple overall. Multiple small classes tend to be more "simple" (in many cases) rather than fewer large classes. Plus it seems like you are conflating two issues: how you design your classes vs. how you design your database. The two do not need to be related.
In your given case, it ...
3
To answer your question directly:
A player would tell (by picking it up) an item to move from one tile to another. So logically, the move method goes on Item and receives the two Tiles as parameters.
Now having said that:
Don't let DDD get in the way of single-responsibility principle. It's ok to have non-entity items, such as MoveManager, and call it ...
3
Ideally, you want to minimize entity state synchronization to avoid unnecessary DB access, so in cases where you don't have to worry too much about resource conflicts, optimistic locking works well.
There are three phases to optimistic locking:
Begin: Record a timestamp marking the transaction's beginning.
Modify: Read and write database values.
Validate: ...
3
OK, here goes for me. I'll pre empt this by saying that:
Premature optimisation (and that includes design) can often cause problems.
IANMF (I am not Martin Fowler) ;)
A dirty little secret is that on small sized projects (even arguably medium sized ones), it's the consistency of your approach that will matter.
Authorization
For me Authentication and ...
3
user.Disable(customer) almost seems like it's saying that user is being disabled, since user.Disable() would read like it's acting on the user, not the customer.
user.DisableCustomer(customer) reads a little better, I think, as it makes it clear that the customer is being disabled. It also means you don't need an extra class just for the sake of it.
3
You're confusing KISS; simple isn't referring to simple to implement for the developer, it refers to simple design, simple to understand and use. Following SRP makes your code simpler to understand and use because it's simpler to use a purpose built class for a single purpose than a multipurpose class, it's also simpler to maintain.
SRP supports Simplicity, ...
2
Jimmy Nilsson touches on this topic in his book on DDD. He started with an anemic model, went to non-anemic models on a later project and finally settled on anemic models. His reasoning was that the anemic models could be re-used in multiple services with differing business logic.
The trade off is the lack of discover-ability. The methods you can use to ...
2
Authorization. Should the domain object be responsible for maintaining its access control rules
No. Authorization is a concern unto itself. Commands that wouldn't be valid due to a lack of permissions should be rejected before the domain, as early as possible - which means often we will even want to check authorization of a potential command in order to ...
2
In response to the EF Vote of No Confidence article, Tim Mallalieu writes:
We are not recommending that folks
return to the days where we were
evangelizing the use of XSD for
“canonical schemas”. I don’t believe
that people think that this is
tractable. What we do believe,
however, is that it is desirable to
have a single meta-model (EDM if ...
2
Classic DB answer: "it depends"
A question:
Are you allowed to add an item to any category, whether parent of not?
That is, can a category have either sub-categories or items, but not both?
If yes, your current table is OK
If no, then have a separate self referencing CategoryParent table. Your current category becomes a child of that.
This constrains ...
2
A third party component has its own model expressed in its own language. Moreover, generally the third party component addresses a general-purpose problem which is normally a portion of the more context-specific problem you are trying to solve.
The first thing to do is be aware that your model, and the third party one are different and form two separate ...
2
Not sure that there is a 'one true way' answer for a design approach that, to be fair, is still evolving. First, DDD and CQRS are not the same thing although the CQRS folks seem to have derived from a DDD-influenced starting point.
There's a lot going on in the DDD mindset and much of it has to do with properly defined boundaries of problems, communication ...
2
However, if I wanted to continue to use the MDA tool for the ORM part
of the application, the model created here would be very anemic (i.e
not contain any business logic).
I don't know which MDA tool you're using, but the ones I've worked with always create partial classes so you're free to complete them with as much business logic as you want.
...
2
My suggestion is rather than making different User classes for different roles, have a single User class that contains a list of Role objects. Role would be a base class, with Manager, SystemOwner, SecurityAdmin, and SystemAdmin being derived classes, with fields specific to their needs. Manager would have a list of subordinates, SystemOwner would have ...
2
You just have some wireup class that populates the domain objects (say, something called "repository"). You can implement lazy loading or whatever kind of cache coherence scheme you want and the domain objects are none the wiser. You're separating the responsibility of populating domain objects from being domain objects.
2
The whole purpose I'm trying to achieve is to quickly get a grasp of the domain I'm modelling and customize it to my needs.
There are books and other resources specially in the area ERP that discusses domain model (at least at a high level). However, for a system such as Library Management, you may not find much in the public domain.
You could still ...
2
The business analyst for my current team does exactly the same :) I wouldn't say it's commonplace, but it is a typical flaw for someone with a technical background who evolved into a business analyst/domain expert.
There are many ways to model a domain, from UML diagrams to words on a whiteboard to drawings on a piece of paper. The important thing is not ...
2
a) DDD doesn't specify that domain objects shouldn't create domain objects. A domain object can very well create another domain object. An aggregate is responsible for enforcing a consistency boundary around a cluster of entities and value objects. As such, it could very well have behaviors which create entities. For example, the stereotypical sales order ...
2
We want to code to be as simple as possible. We don't want it cluttered up with domain knowledge that the programmer shouldn't need to know. Thus, whenever possible, we want to avoid putting something as domain specific as chemical products into the code. That's why we think that putting chemical products as an enum into your code is probably a bad idea ...
2
Since all your criteria are not strictly geographic, I think what you're looking for falls more closely under faceted search. Faceted search allows the user to "drill down" until they get the information they want, in this case the responsible branch. You see it most frequently on shopping sites. You do a general search, then a list of criteria, or ...
Only top voted, non community-wiki answers of a minimum length are eligible
