141 reputation
4
bio website tesio.it
location Italy
age 33
visits member for 1 year, 7 months
seen Mar 7 at 9:14

I'm able to rapidly identify the independent variables that govern complex problems and to plan a strategy to avoid (or at least to solve) them through the use of the proper tools.

Whenever the current technological offer does not match to my requirements, I can design and develop the missing tools or hack into existing ones.

During the last 5 years, I've gained some experience with Domain Driven design and supporting architecture and I'm building Epic as a "DDD software factory" that aims to make DDD much more cheaper than it is now. I've also contributed to various opensource projects with patches and bugfixes.


Apr
9
comment A design decision in composition or aggregation
No I stated that Slot is not a domain object because of it's equality implementation. And BTW, it's up to the domain expert to state what is part of the domain model and what it's not. Moreover cyclic reference between objects are always a weird smell, to avoid everytime it's possible.
Apr
9
comment A design decision in composition or aggregation
Really?!? :-D I can't promise it soon...
Mar
27
comment Unit Testing in a “no setter” world
@SonOfPirate you are right, it's just a memento pattern applied to unit tests. I've never realized that. :-) It's not that fragile anyway. You just need the proper tools.
Mar
22
comment Unit Testing in a “no setter” world
Changing implementation that way is quite rare, since it's dangerous by itself. Indeed with such kind of changes affect the clients in subtle and unexpected way. I can't remember of such kind of changes in the domain code in the last 2 years, since most of times if you change internal behaviour, you will change the external API, too. BTW... if you have other doubts about this testing approach, you can simply try it on real world domain models.
Mar
22
comment Unit Testing in a “no setter” world
When someone changes the public method that was used to prepare the serialized state, the class that contains the Action<TEntity> to execute can not compile. Such compilation errors remind us to fix the states. As said, this is not a theoretical suggestion: it's how I ensure such kind of unit test isolation (when required), and I can grant that it works pretty well in real world DDD applications.
Mar
21
comment Unit Testing in a “no setter” world
After the snapshots are produced, they are stored in files. Each tests does not depend on the sequence of the operations required to obtain the starting state of the entity, but from the state itself (loaded from the snapshot). The method under test itself is then isolated from changes to the other methods.
Mar
21
comment Unit Testing in a “no setter” world
I have written a small tool for that. It load a class by reflection that create a new entity using it's public constructor (typically taking just the identifier) and invoke an array of Action<TEntity> on it, saving a snapshot after each operation (with a conventional name based on the action's index and the entity name). The tool is executed manually at each refactoring of the entity code and the snapshots are tracked by the DCVS. Obviously each Action calls a public command of the entity, but this is done out of the tests runs that this way are truly Unit test.