Tag Info

Hot answers tagged

44

Your boss should read this piece: Bad Carma: The "Vision" project, a cautionary tale about inner platform effect or second system effect. Abstract Those of us who work in Information Technology (IT) have all been on a project where something important is just not right. We know it, most everyone knows it, but nobody is quite able to put his or her ...


33

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


29

For me, it is definitely best to change everything related to the item in question. It is a form of code degradation, and while 1 item not being changed might not be a big deal, it sets the tone for the code base. It could also lead to confusion in the future and make it harder for new devs to understand the code base/domain.


22

I cannot put the object into the state needed to perform the tests. If you cannot put the object into the state needed to perform a test, then you cannot put the object into the state in production code, so there's no need to test that state. Obviously, this isn't true in your case, you can put your object into the needed state, just call Approve. I ...


19

The lines can be a little blurry, but I see it this way: A Service class/interface provides a way of a client to interact with some functionality in the application. This is typically public, with some business meaning. For example, a TicketingService interface might allow you to buyTicket, sellTicket and so on. A helper class tends to be hidden from the ...


18

There's an interesting article by Martin Fowler on that subject that highlights an aspect most people (including me) tend to overlook: But one thing that I think constantly trips people up is when they think object validity on a context independent way such as an isValid method implies. I think it's much more useful to think of validation as ...


18

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


16

Well, first of all, I don't think that the Wikipedia article you refer to is very good, mostly because it references a bunch of things that are only ancillary to Domain Driven Design and does little to enlighten anyone about the practice. But, as someone who has taken Domain Driven Design to heart (which usually goes by DDD, rather than 3D, for what it's ...


15

The answer is yes, it is possible to create a fully data-driven system and yes, it's usually a really bad idea. A fully data driven program is one in which all logic and configuration is handled by values stored in such a way that in another context they would be regarded as data. There were many 4GL products produced in the 1980s that provided the ...


14

Dependency Injection and DDD are two disjoint concepts. Doing Dependency Injection does not require to do DDD nor does DDD require Dependency Injection. A lot of DDD projects fail because they pick the patterns but neglect the process behind DDD. They do not take the time to extract business rules. They do not concentrate on the domain model and on careful ...


13

The complexity of the business logic, alternatively called the application behavior, is the most important factor. The second most important factor is how much of a gap there is between the technical problem and the business vocabulary used to describe that problem, since DDD is about creating a shared vocabulary between the business and the engineering ...


12

POCO stands for plain old c# objects. It comes from the java equivalent POJO. It's just a hip name to show the world that not everything has to be a derived class. POCOs are not necessarily DTOs, they can be full blown objects with behavior and state and clild POCOs, while DTOs only have state. Now about your domain - if as you say you are trying to do ...


12

The blue book is definitely worth a read if you want to get the best out of the DDD approach. DDD patterns are not trivial and learning the essence of each of them will help you ponder when to use which pattern, how to divide your application in layers, how to define your Aggregates, and so on. The group of 2 entities you're mentioning isn't a Bounded ...


11

Computation using immutable objects (as in functional programming) does not necessarily imply persisting every object that is generated!


11

Your problem seems to step from the fact that the "customer" is probably a person who will not use the system. Some things I remember from SE class: Try visiting the people who will actually use the system and observe them in actual working conditions. This can be important because of domain differences between users and developers, difference assumptions ...


11

Let's imagine I have a Groups and Users and when user wants to join a group, I'm calling groupsService.AddUserToGroup(group, user) method. In DDD I should do group.JoinUser(user), which looks pretty good. But DDD also encourages you to use (stateless) services to perform tasks, if the task at hand is too complex or would not fit into an entity ...


11

The correct answer was given by Alexey Zimarev and got at least 7 upvotes before a moderator moved it into a comment below my original question.... His answer: I would recommend you to watch Jimmy Bogard's NDC 2012 session "Crafting Wicked Domain Models" on Vimeo. He explains what rich domain should be and how to implement them in real life by having ...


11

From the question content and tags I'll assumer you're using ubiquitous language. In my experience UL is great but, as you mentioned, can lead to additional maintenance tasks as the language evolves. This, in itself, isn't a bad thing. Sure, it's inconvenient, but it's also expected. What I've typically done (and seen done) is either: 1-shot upfront ...


10

Consider a company that has a few different departments: Software Development HR Accounting Can you come up with a user model that can expressively represent all those areas of business? Think of what the User entity could look like in each one. Perhaps it's split into three different entities: Developer Employee Payee The effort to instantiate a ...


9

If your core entities are plain DTOs, then it might be considered an anemic domain model. I never liked the idea of moving logic to services - looks like a crutch to fix ugly persistence architecture.


9

This question is somewhat subjective and leads to more of a discussion than a direct answer, which, as someone else has pointed out - isn't appropriate for the stackoverflow format. That said, I think you just need some coded examples on how to tackle problems, so I'll give it a shot, just to give you some ideas. The first thing I'd say is: "domain ...


8

I've been a big fan of DDD for a while (with and without the safety net of a test framework). The whole concept and lifecycle of refactoring doesn't change because you're now using a new design methodology. If it will take significant time, it has to have proportional benefit to the project in order to get that time from management. With respect to doing ...


8

If you're going Domain Driven, consider treating your Trade class as an aggregate root and break its responsibilities out into other classes. You don't want to end up with a Trade subclass for each combination of price and risk, so a Trade may contain Price and Risk objects (composition). The Price and Risk objects do the actual calculations, but aren't ...


8

The theory: A class should be responsible for its data and know what to do with its data. Any methods that the class needs to enforce that responsibility should be within the class. In Practice: So the class will have User.Name and it should also have User.GetName(), User.GetFirstName(), User.GetLastName() as Name belongs to the User and the User should ...


8

I can give you another example. Consider you have some ecommerce system. You would have products there, however products will be part of at least two different domains: Product catalog, where you keep your product description and all attributes Inventory, where you have product stock level If you have one bounded context for both domains, your solution ...


7

IS this a read-only situation? Because that's what it sounds like. If you're doing DDD, then whenever you need to update/create something in your app you're going to go through the domain model because that is going to contain all of your business logic and validation. However, there are times in your application when you just want to aggregate together ...


7

Does immutable in the domain mean it has to be immutable in the database? For example consider the following assuming customer always has one address: customer.address = new Address('My Castle', 'Kings street'); customer_repo.save(customer); now the following sql is run considering the customer id is 1: INSERT INTO addresses (customer_id, name, street) ...


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 a scientific definition, but my general take is a service class has some context within the application whereas helpers are more generic and don't care what app they are helping.



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