7

In general DI should be supported in libraries. The actual implementation or selection of a DI Container should not be done by a library, that should be left to the root application. That way the root application can decide on whether or not to use DI what DI library to use which other dependencies to load/pass on to the library DI support can be ...


6

It is unfortunately a popular form of DDD. I say unfortunately because it completely ignores the core principles of DDD, that is the actual modeling of the problem. Having pure data structures does nothing to tell the reader what is happening, what problems are being solved, it does not use the Ubiquitous Language, since getting/setting stuff is rarely if ...


6

A timestamp is a value object: it has no identity and is solely defined by its value components. In your case you could use a built-in type or go for your own value-type (eg a C# struct). A value object can be a property of a larger object. Especially if it’s a value-type (There could be some subtle differences if your language would not support value ...


5

This characteristic is opposed to a monolith and means that you don't need to deploy two services sie-by-side. In a case of a monolith, if you want to deploy a change in one part, you have to deploy the whole monolith. This means that you have essentially three problems: Say you're ready to deploy your change, but the other team working on another part of ...


5

Truly independent deployment means you can upgrade either service in any order and stay in a working state. Obviously, having no dependencies at all is ideal, but somewhat impractical. If you have dependencies between microservices, you can still deploy them independently: In your example, microservice 2 can be upgraded at any time, provided it maintains ...


3

I see this as strict separation between the domain model and the persistence model. By duplicating this model, it becomes possible to fine-tune models for their specific purpose. One represents business rules, other is easy to persist and query. If it was just single model, it would be necessary to make tradeoff-s between the two. This is specific way to ...


3

This might sound naive, but the way to don't violate SoC is not doing it. Don't integrate the password with User because it belongs to another domain. Security. In security, the counterpart of User could be (and often is) Account. Account and User are correlated. Account hold reference to the password or a set of Credentials. It depends on the security ...


2

An address object (which refers to a street address) can be modeled either as a value object or as an entity. The trade-off lies mostly in the database/storage layer. If you design your storage to assign an ID to your address object, you are effectively choosing to treat your address objects as entities. If you want to treat addresses as value objects, you ...


2

It seems to me like the fundamental problem you are getting at is the need to generate the Message objects as you call methods/fields on your Domain objects. There's not much you can do about this if you want to do Event Sourcing. If you keep the simple ItemRepository, then when you call Save(Item) the underlying event source database has no way to work out ...


2

The core argument for using repositories is to prevent leaking EF dependent code into your domain. That argument is not wrong, it just comes with a steep cost, i.e. a high-complexity uow/repo layer, which is now being regarded (by some, at least) as too high a price to pay for what it gives back. By not using that uow/repo layer, you do actually let your ...


2

A value object is an object that has no identity but is fully defined by its value. A timestamp fully fits that description, and so does an integer and a string. At the same time, a timestamp can also be a property of a larger object. It is not a matter of choosing between either a value object or an attribute, because it is very normal for value objects to ...


2

Api.EmployeeController.Update(Api.EmployeeUpdateDto) => Services.EmployeeService.Update(Service.EmployeeUpdateDto) => Data.EmployeeRepository.Update(Entities.Employee) => Data.EfDbContext.Employees.Update(Entities.Employee Let's look at it this way: what if you were to tell your business counterpart this? Just the above word-for-word. I would wager he/she ...


1

Greg Young's Polyglot Data talk includes a discussion of pull vs push. Pub/sub is "fine" when you are dealing with a single message in isolation. It's also a reasonable choice when you need to handle sparse events with low latency. But pull based solutions are a lot easier to reason about when you are dealing with sequences of messages. The consumer ...


1

Having multiple value objects of the same type relate to an Entity is a common use-case. What I usually do is to model my value objects differently, and try to understand if it's better to have a collection of value objects relate to the entity. So in your case, your value object is actually an AddressCollection value object (in your code) and you can ...


1

To me, this is important because you can release changes in small batches and manage integration regressions much more easily. With a monolith, you make a change to some feature area, build and deploy the entire thing and hope it goes well. With independent services, it's much easier to roll out small chunks and make sure they continue to play well. Let'...


1

Since my initial post of this answer didn't accomplish what I wanted, I purchased the for-Kindle version of this book, and found exactly what I vaguely remembered, in order to directly answer the question Why do we need so many classes in design patterns? Short and sweet -- we don't. Exactly why that is true I'm not sure that I can put into words as ...


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