isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <...@haywood-associates.co.uk>
Subject Re: value type or entity type
Date Mon, 08 Apr 2013 23:04:25 GMT
On 30 March 2013 00:17, 张峰昌 <alain.zhang@gmail.com> wrote:

> Hi,Dan
> Thanks a lot for your advice.
>

But sorry I haven't replied sooner to this next question of yours on this
thread...


The new problem about using java enum to model is:
> (1).how to model unlimited nested subtypes relationships. ex: "Customer"
> is a Party Relationship Type,while "Billing To Customer","Place Order
> Customer" are two subtypes of "Customer" Party Relationship Type,especially
> the value set is not very defined at system design time,generally at
> deployment or runtime?
>

Yes, obviously enum only works for a bounded set of variations.

However, it ought to be possible to identify that bounded set of
variations, and thus your enum.  I might go so far as to say it must be
possible to identify that bounded set of variations.

To explain: most properties of entities are "just" data; its value does not
change the entities behaviour.  An example might be the name of a customer,
say.

But in other cases the behaviour of the entity changes because of the
value.  A good example is an OrderStatus, being an enum, such that the
Order could delegate to its associated OrderStatus for any of its behaviour
that depends on its status.... ie the "objects for state" pattern.

Somewhere in the middle we have values of properties that may or may not
affect the behaviour.  For example, the value of an Address might change
the shipping costs if overseas, or it might not.  The interesting thing
here would be to distinguish between the overseas case vs internal.  And so
in this case we have got to a (rather trivial) derived enum: enum
ShippingCosts { OVERSEAS, INTERNAL }

~~~
with respect to the example you raised, I don't think it is correct to
model BillingToCustomer and PlaceOrderCustomer as subtypes of Customer.
 Rather, I would say that the Customer has a reference to a BillingStrategy
(or whatever), and this BillingStrategy is the enum.


(2).can value type including java enum using domain services when
> implements behavior in isis?
>

Sorry, I couldn't parse this question.  Can you rephrase?


>
> BaseString may be powerful than enum     I think. The reason may be:
> (1)."name","type","description" may not can be enumerated at design
> time,but they did have some special rules.So we  should model them with
> some techniques.
> (2).we needs simple ways when needs new business value
> type.BaseString,BaseNumber etc should provide us simplicity for us.
>
>
Yes, it is on the todo-list, as I say.  In the meantime, use
@MustSatisfy(SomeSpecification.class).


Cheers
Dan


Best Regards
>
> Alain
>
> 发自我的 iPhone
>
> 在 2013-3-29,16:12,Dan Haywood <dan@haywood-associates.co.uk> 写道:
>
> Hi Alain,
> I'm cc'ing this to the users@iao mailing list in case anyone else wants
> to chip in as well.  My answers within...
>
> On 27 March 2013 01:06, 张峰昌 <alain....@gmail.com> wrote:
>
>> Hi,Dan:****
>>
>> ** **
>>
>> I have read the book  *Domain-DrivenDesign Using Naked Objects*. And I
>> have a question about Value Object.****
>>
>> ** **
>>
>> There are so many simple business object which have only a “description”
>> property which describe something abount another business entity,such as
>> :RoleType(describe party role)、StatusType(describe entity status)、TransactionType(describe
>> transaction),etc.****
>>
>> ** **
>>
>> The question is xxxType should be model with value type or entity type in
>> DDD methodology?
>>
>
> In all these cases I'd use an enum.  This is a value type.  In Java (as
> you know I am sure), you can create subclasses, which also gives them
> behaviour, eg:
>
> public class Order {
>     private OrderStatusType statusType;
>     ...
>
>    public void foo() {
>       statusType.foo(this);
>    }
>    public void bar() {
>       statusType.bar(this);
>    }
> }
>
> public enum OrderStatusType {
>     PLACED {
>       public void foo(Order o) { ... }
>       public void bar(Order o) { ... }
>     },
>     SUBMITTED {
>       public void foo(Order o) { ... }
>       public void bar(Order o) { ... }
>     };
>     public abstract void foo(Order o);
>     public abstract void bar(Order o);
> }
>
> We also use enums like this as factories of subtypes (so the enum acts as
> a powertype).
>
>
>
>>  ****
>>
>> I have tried different ways in isis. There are so many repositories about
>> each xxxType in my project,and finally I will loss in many repositories.
>> There are no maintainable capability when I modeled theses types to value
>> type(string datatype),becarseof each value type should be serilized into
>> everywhere that used.And there will be difficult to change the xxxType
>> description according to requirement change in the future.
>>
>
>
> So, I think the above advice works for this, assuming that you have a
> bounded set of instances.
>
> There is a related question, which is the concept of a string-like value
> type to represent a name, or a description, or a country.  Although Isis
> itself does support custom value types (using @Value), the issue you can
> run into is having to teach the JDO objectstore about these types also.
>
> One thing I have as an idea is to introduce some sort of BaseString (and
> BaseNumber, and ...) class that can be easily subclassed but which will
> (somehow, magically, not sure how yet) take care of the JDO objectstore
> serialization too.
>
> For example:
>
> @Value // isis annotation
> @MaxLength(30)  // isis annotation
> @Regex(...)   // isis annotation
> public class Description extends org.apache.isis.applib.helpers.BaseString
> {
>     ...
>
>    public String foo()  { ... } // description-specific behaviour
>    public String bar()  { ... } // description-specific behaviour
> }
>
> A reasonable half-way house is to use Isis' @MustSatisfy annotation, that
> allows one to specify a Specification of a string-like thing against
> strings, ie:
>
> public class Customer {
>
>
>     private String name;
>     @MustSatisfy(NameSpecification.class)  // this *is* supported by Isis
>     public String getName() { ... }
>
> }
>
> In this case the business rules associated with the concept of "Nameness"
> are encapsulated into the NameSpecification.
>
> HTH
> Dan
>
>
> ****
>>
>> ** **
>>
>> Could you have any advice about the value type or entity type?****
>>
>> ** **
>>
>> Thanks a lot.****
>>
>> ** **
>>
>> Best Regards****
>>
>> ** **
>>
>> Alain****
>>
>> ** **
>>
>> 张峰昌****
>>
>> 电话:18930623939****
>>
>> ** **
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message