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


34

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


21

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


19

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


19

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

Your application should still be modelled from domain driven design principles. Whether you use an ORM, straight JDBC, calling SPs (or whatever) should not matter. Hopefully a thin layer abstracting your model from the SPs should do the trick in this case. As another poster stated, you should view the SPs and their results as a service and map the results ...


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


14

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


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


13

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


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


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

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


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

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

If you are building a simple application with low traffic, there is something to be said about keeping another component out of your system. It is very likely not using a message bus is the right answer for you. However, I would suggest building your system in a way you could swap out the database based queue system for middleware solution. I agree with ...


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

Taking from Martin Fowler's patterns of enterprise design, the most common layers are: a) Presentation - these are views, presentation templates which generate the interaction interface for your application (I am using interaction in case your application is accessed by other systems through web services or RMI so may not be a user interface). This also ...


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


9

Disclaimler: I'm only taking my first steps in the CQRS world, but I can offer my current understanding of the matter and we'll see if others confirm. All I write below has an underlying "as I see it" theme, and is not authoritative. The 80% case To answer your question, commands are indeed a point-to-point affair. When a command enters a controller (MVC ...


9

Let the application service call both methods The application service is usually a great starting place for this, however you should always try to shift behavior as close to the entity as possible. The application service plays an orchestrating role and it sets up the stage for executing domain behavior and as such it provides all required dependencies. ...


8

Don't use your Domain Model and aggregates for querying. In fact, what you are asking is a common enough question that a set of principles and patterns has been established to avoid just that. It is called CQRS.


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



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