domain-driven-design

问题 If I have to create a domain model object in C# I might do something like this: public class Person { Public string Name { get; set; } Public string Gender { get; set; } Public int Age { get; set; } } In Javascript, what is the convention for defining such objects? I'm thinking something like this: NAMESPACE.Person = function() { this.name = ""; this.gender = ""; this.age = 0; } 回答1: Yeah, spot on basically. The only thing to add is that you should prototype methods on. How you proto can be

问题 We're to use DTO's to send data to and from the presentation layer. We have layers like: facade appService domain And We have use Dozer to help us convert entity to dto. But i have 2 question now: from entity to dto we can use dozer, but from dto to entity can we use dozer? If Yes, How? Where shoud i create entity? in facade or DTOAssembler? for example,I have to register a book. the book Entity look's like: Book{ public Book(BookNumber number,String name){ //make sure every book has a

问题 There are classes that are entities according to DDD, and there are classes that have @javax.persistence.Entity annotation. Should they be the same classes? Or should JPA entities act just as a mechanism for a mapper (https://martinfowler.com/eaaCatalog/dataMapper.html) to load DDD entities from a database (and store them) and be kept outside the domain model? Would it make a difference if database metadata were separated and stored externally (for example, in XML)? If such classes are

问题 I am busy reading, and enjoying, Dependency Injection in .Net by Mark Seemann. It is quite difficult for me to explain the exact context, so please only bother with this question if you are familiar with the book. My question has to do with the two Product classes in chapter 2 pg 49. There is one in the Domain layer and one in the data access layer. It is explained that Product class in the data access layer was created by the Linq to Entity wizard. I am working with Linq to SQL, and I could

问题 In many leading DDD projects, especially MVC style, I see the UI using display objects that mirror domain entities, rather than using those domain objects directly. This style is obviously for decoupling and separation of concerns, and I personally prefer this style. But what I'm not sure of, is whether this a strict tenet of DDD, or whether this is more just different developers' interpretation of it. Can you use your domain objects directly in the UI, and still be following the DDD

问题 Background I'm trying to create a simple application to really understand the whole stack of DDD+TDD+etc. My goal is to dynamically inject the DAL repository classes at runtime. This keeps my Domain and Application Services layers testable. I plan on using "poor man's DI" to accomplish this for now ... so I would do this in a simple Console application near startup: // Poor man's DI, injecting DAL repository classes at runtime var productRepository = new SimpleOrder.Repository

问题 Background I'm trying to create a simple application to really understand the whole stack of DDD+TDD+etc. My goal is to dynamically inject the DAL repository classes at runtime. This keeps my Domain and Application Services layers testable. I plan on using "poor man's DI" to accomplish this for now ... so I would do this in a simple Console application near startup: // Poor man's DI, injecting DAL repository classes at runtime var productRepository = new SimpleOrder.Repository

问题 I'm trying to implement fully valid persistence ignorance with little effort. I have many questions though: The simplest option It's really straightforward - is it okay to have Entities annotated with Spring Data annotations just like in SOA (but make them really do the logic)? What are the consequences other than having to use persistance annotation in the Entities, which doesn't really follow PI principle? I mean is it really the case with Spring Data - it provides nice repositories which

问题 In the book Domain Driven Design, by Eric Evans, in Chapter 6 in the section on "Factories" (page 139) it says the following: "The two basic requirements for any good FACTORY are: ... "2. The FACTORY should be abstracted to the type desired rather than the concrete class(es) created." Could you please elaborate on what is meant by that statement about basic requirement number 2. 回答1: Carlos Loth's answer is correct, but you should always remember to use an Abstract Factory as well, as this

问题 I am currently working on a project where I have a BankAccount entity for some other entity. Each bank account as a reference to a bank entity, an account number and optionally an IBAN. Now since an IBAN can be validated, how can I ensure that when the IBAN is set for an account is valid. What would be a clean architectural approach? I currently have a domain layer without any reference to any other layer and I like this clean approach (I was inspired by Eric Evans DDD). Fortunately the IBAN