Hot answers tagged

108

The specification is virtually never sufficient. Developers who do not have domain knowledge cannot point out when the specification is in error (a frequent occurence most places) and make poor design choices.


62

I've been in this situation before. First of all, don't say no. Never refuse to provide people with answers to their questions. Instead try to guide them into an "appropriate" way of getting those answers. This is what worked for me: If you're not the right person for the question, redirect them instead of answering yourself. This prevents you becoming ...


60

In my experience, having worked in 3 very different industries now, you can start out not knowing much about the domain, but you'll need to learn it eventually and someone will have to understand it to a detailed degree. The essential problem is down to the client-developer impedance: they want something but will only know it when they see it and you want ...


45

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 ...


27

Martin Fowler's first law of distributed systems: "Don't distribute your objects!" Remote interfaces should be coarse-grained and internal interfaces fine-graned. Often rich domain model only applies within a bounded context. REST API separates two different contexts both having their own internal models. The contexts communicate through coarse-grained ...


22

What about producing a Wiki, so you can share that knowledge so when people come and ask you can say, "have you looked at the wiki?" and then that grows into a excellent documentation resource, as people should add their experience to it. Where I work we do this and I found over time I only got asked questions that were not so obvious as they were answered ...


17

Don't say no. But don't answer immediately either. Make it clear that: you like to help out, you have your own work to do, you need to be able to do so without being interupted all the time and ask your co-workers to: batch questions so you work through a number of them in one sitting, work on something else if they have a question that means they ...


15

SOMEONE on the project needs to have fairly complete domain knowledge. That person may or may not be the developer. In Agile projects, the client project owner is that person, and they're working collaboratively and closely with the team. In non-Agile projects, somebody on the team needs to acquire that knowledge, but they usually don't, which is one reason ...


11

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 ...


10

Finding a suitable model isn't always straight forward. It is one of these things which require more experience than plain knowledge. However, the following simple recipe might help you to get over an initial mental block. It was originially described in this paper by Abbott and is frequently referred to as "Abbott's textual analysis". Write a plain text ...


10

Talk to your manager and explain the situation. It is his job to ensure you are productive and can do your job effectively. One possible solution could be a "question hour" - where you can only be approached for questions within that one hour in the day and would be off-limits otherwise. As for widespread knowledge sharing - there are several ways to do ...


10

There are a lot of excellent answers. I add my own because after reading them and searching I found that nobody mentions a key issue: bugs. If the team is not provided with enough people with enough authority and domain expertise, sooner or later bugs will inevitably creep in. Given a knowledge of the domain, there are impossible, or non-sensical values/...


9

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 ...


8

If you put a person who knows only English and a person who knows only Japanese in a room, they wouldn't be able to translate from Japanese to English, in spite of being experts of their respective languages. For the same reason, even expert programmers with no domain knowledge are powerless at figuring out what they needs to build, even when they have a ...


8

POST was deliberately designed to be "intentionally vague;" the result of a POST is implementation-specific. What prevents you from doing what Twitter and other API designers do, and define each POST method in the non-CRUD portion of your API according to your own specific requirements? POST is the catchall verb. Use it when none of the other verbs are a ...


7

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 ...


7

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 ...


7

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 ...


7

Without some aspect of business knowledge you end up with developers who don't ask questions and mindlessly code what the specs say. I believe it takes "Thinkers" to make good software not just people who can bang on a keyboard. Understanding not only "What" you are doing but "Why" and how it fits into the bigger picture helps provided greater satisfaction ...


7

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 ...


7

It depends. If your Account class shall be mapped to a relational database, then its not just a good idea, but proven practice, to use technical IDs for every table as PKs (and FKs, referencing those PKs). To my experience, separating the technical PK of all tables from the "domain keys" (like the "bank account number") works very well and helps you to avoid ...


6

We had a similar situation in our office that is shared between developers, testers, and the relatively small help desk. When the help desk got a question they couldn't answer, they would ask a developer or tester for assistance. Over time, the help desk people asked fewer questions overall but they began asking the same person all the time because that ...


6

I think you should try to get the domain knowledge. Specs are check list saying what the end product should do and is required for the validation of your product. As developer you should always try to understand what is the real problem you are trying to solve. Getting the domain knowledge will help you understand that. It will help you design and code ...


6

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, ...


6

That's exactly one of the reasons why DTOs exists. The tradeoff here is that adding DTOs makes your implementation a bit more complex, and thus prone to errors - such as a mismatch in mapping the domain object to a DTO. Use unit tests for this! Another thing that you could do with your DTO and tends to be highly overlooked in RESTful services is treating ...


6

Looks like the purpose of the model is missing from the picture. DDD is not about modelling reality: it's about discovering the model which is the best fit for the specific purpose. Design patterns will eventually follow.


6

In general I prefer composition over inheritance. That has several reasons: Humans are bad at dealing with complexity. And dealing with high inheritance trees is complexity. I want light structures on my brain, which I could overlook easily. The same goes for dozens of types even derived from one base class. You are able to switch moving parts out. You ...


6

If you can give the class enough useful functionality to justify the added complexity of not being a string, then do it. For identifiers like ISBN and ISIN, I suspect this is not the case. For an identifier class to be useful, I'd expect it to look something like this: class ISIN { fromCUSIP() fromRawISINString() toString(ISIN::FormatType) ...


6

I would say go for it. I would argue that the advantages outweigh the disadvantages in this case. The extra code is likely to be pretty minimal and the persistence issue can be solved pretty easily be providing some sort of converter between your new Class and the type the database expects (I've never used Entity Framework but I know this is relatively ...


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 ...



Only top voted, non community-wiki answers of a minimum length are eligible