The Stack Overflow podcast is back! Listen to an interview with our new CEO.
336

This is an optimization problem A good engineer understands that an optimization problem is meaningless without a target. You can't just optimize, you have to optimize for something. For example, your compiler options include optimizing for speed and optimizing for code size; these are sometimes opposite goals. I like to tell my wife that my desk is ...


109

The domain is the real-world context in which you're attempting to solve a problem using software. Each domain comes with expertise, vocabulary and tools that are part of that domain. A specific example of a domain could be something like "the automated machining of intricate parts using a high-speed rotating cutter." The software and hardware system that ...


77

This is not brittle in the usual sense. A unit test is considered brittle if it breaks due to implementation changes which does not affect the behavior under test. But if the business logic itself changes, then a test of this logic is supposed to break. That said, if the business logic indeed changes often, perhaps it is not appropriate to hardcode the ...


73

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


67

Well, first of all, readability and maintability are often in the eye of the beholder. What is readable to you may not be to your neighbour. Maintainability often boils down to discoverability (how easily is a behaviour or concept discovered in the codebase) and discoverability is another subjective thing. DDD One of the ways DDD helps teams of ...


59

The most helpful 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 ...


46

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


46

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


41

GUIDs are by definition "Globally Unique IDentifiers". There's a similar but slightly different concept in Java called UUIDs "Universally Unique IDentifiers". The names are interchangeable for all practical use. GUIDs are central to how Microsoft envisioned database clustering to work, and if you need to incorporate data from sometimes connected sources, ...


38

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


38

Bounded Contexts and Subdomains exist at different levels. A Subdomain is a portion of the problem space, it's a natural partitioning of the system, often reflecting the structure of the organisation. So logistics and operations might be separated from invoicing & billing. Eric differentiates core, supporting and generic subdomains according to their ...


38

It simply means the problem space you are working in. For example, if you were building an e-commerce website your domain would be "e-commerce" and would involve the processes associated with your client/company's sales practices. So a domain model would be something to represent a product or an invoice or a shipping record.


38

These days, you are likely to see reads (queries) handled differently than writes (commands). In a system with a complicated query, the query itself is unlikely to pass through the domain model (which is primarily responsible for maintaining the consistency of writes). You are absolutely right that we should render unto SQL that which is SQL. So we'll ...


34

I recently read DDD myself. When I got to this section I was pleasantly surprised to find out I discovered the same 4-layer architecture that Evans did. As @lonelybug pointed out, the domain layer should be completely isolated from the rest of the system. However, something has to translate UI-specific values (query strings, POST data, session, etc.) into ...


33

Usually, services call other services when they need to access their data. Each piece of data should belong to a particular service which will be the only entry point to accessing this data and modifying it. Some services will be simple and usually correspond closely to your domain model (e.g. a service for handling users) while others will be high-level and ...


31

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.


29

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


29

Does this kind of validation lives in the domain or application layer? Application. The magic search term you want is anti corruption layer Typically, the message received by your application will be some flavor of DTO. Your anti corruption layer will typically create value types that the domain will recognize. The actual command dispatched to the ...


29

The short answer is - you can use repositories from an application service, or a domain service - but it is important to consider why, and how, you are doing so. Purpose of a Domain Service Domain Services should encapsulate domain concepts/logic - as such, the the domain service method: domainService.persist(data) does not belong on a domain service, as ...


29

Please explain me, why do we need this DDD style, lots of Patterns? First, a note: the important part of DDD is not the patterns, but the alignment of the development effort with the business. Greg Young remarked that the chapters in the blue book are in the wrong order. But to your specific question: there tend to be a lot more classes than you would ...


29

There are many good points in the other answers, but I think they miss or don't emphasize an important conceptual mistake you make: You are comparing the effort to understand the complete program. This is not a realistic task with most programs. Even simple programs consist of so much code that it is simply impossible to manage all of it in the head at any ...


28

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 that 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 a middleware solution. I agree ...


28

Will this always be unique? Always? no, not always; it's a finite sequence of bits. Say I had a database containing millions and millions of rows with a GUID as the Primary Key. Millions and millions, you are probably safe. A million millions, and the likelihood of a collision becomes significant. There's good news, though: you've already run out ...


27

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


25

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


24

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.


23

Taking from Martin Fowler's patterns of enterprise design, the most common layers are: 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 ...


23

It is up to you. Most people will tell you that it's not a good practice but you can get away with it in some cases. EF never played nicely with DDD for multiple reasons, but two stand out: you can't have parameterized constructors on your entities and you can't encapsulate collections. DDD relies on that, since the domain model should include both data ...


22

This folder structure is inspired by the famous Implementing domain driven design book by Vaugh Vernon. Solution: ├ WebService (REST Services reside here) ├ WebServiceTests ├ Application (Application services reside here) ├ ApplicationTests ├ Domain (Entities, VO, Domain services, domain factories, specifications, domain events, Repositories interfaces, ...


21

You might be overinterpreting the book. It basically says : anything outside an Aggregate cannot hold a reference to anything inside it except the root. Therefore, holding a reference to a root is legit. Holding a reference to a root doesn't mean it's part of your own aggregate and that you can control its invariants. It keeps its own invariants and autonomy....


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